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1BSTBACT 


The  Computer  Performance  Modeling  Tool  (CPHT)  is  a 
queueing  network  siaulator  to  be  used  in  support  of  Computer 
Performance  and  Evaluation  courses  like  C54400.  This  thesis 
is  a  continuation  of  the  CEHT  development  project  and 
consists  of  adaptive  and  perfective  maintenance  work  to 
modify  the  existing  simulator  to  add  extended  modeling 
capability  and  to  improve  the  siaulator  performance.  The 
thesis  effort  also  included  rewriting  the  CPST  user’s  manual 
to  reflect  new  features,  establishing  a  change  log  for  the 
program  and  continuing  validation  of  the  siaulator. 
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The  Computer  Performance  Hodeling  Tool  (CPMT)  is  a 
queueing  network  simulator  designed  to  model  computer 
systems,  and  it  is  written  in  PASCAL  for  the  VAX- 11/VMS 
environment. 

This  thesis  describes  a  development  and  enhancement 
effort  to  improve  the  performance  and  modeling  capability  of 
the  CFHT  simulator. 

A.  BACKGBOOHD 

1 •  Overview  of  the  Computer  Performance  Evaluation 

MMs 

The  application  of  computer  performance  and 
evaluation  includes  the  analysis  and  enhancement  of 
performance  of  existing  systems  and  the  prediction  of 
performance  of  planned  or  projected  systems.  Performance  of 
existing  systems  can  be  evaluated  via  measurements,  using 
hardware  and/or  software  monitors,  either  in  a  user 
environment  or  under  benchmark  conditions.  However,  the 
interactions  in  present  day  computer  systems  are  so  complex 
that  some  fora  c£  modeling  is  necessary  in  order  to  tune, 
predict,  and  understand  computer  system  performance. 
Performance  modeling  is  also  widely  used  during  design  and 
development  of  new  systems. 

Networks  of  gueues  and  Harkov  chains  are  the  most 
common  representations  of  computer  systems.  Queueing  models 
are  analyzed  by  mathematical  techniques  employing  applied 
probability  theory  [Bef.  1]. 

The  increased  complexity  of  many  computer  systems 
as  a  result  of  inclusion  of  different  resource 


models 


scheduling  algorithms,  makes  the  design  of  models  difficult 
and  makes  the  utilization  of  mathematical  ,  analysis 
unreasonable.  In  such  cases  it  is  necessary  to  use  a  system 
simulation.  A  system  simulation  implies  the  generation  of 
random  inputs  and  the  monitoring  of  distinct  events  in  the 
modeled  system.  Once  a  model  has  been  formulated,  a 
simulator  run  tracks  the  execution  of  the  model  as 
determined  by  the  occurrence  of  events  at  discrete  time 
instants.  The  output  of  the  simulation  are  random  variables. 
Therefore  statistical  analysis  must  be  performed  to  produce 
a  meaningful  statement  about  the  validity  of  the  simulation 
results. 

2.  Computer  Performance  Modeling  Tool  fCPHT) 

CPMT  program  development  began  as  a  class  project 
for  the  Computer  System  Performance  Evaluation  course,  CS 
4400,  taught  at  the  Naval  Postgraduate  School. 

The  objectives  were  the  familiarization  of  students 
with  simulation  program  design,  and  to  produce  a  simulation 
program  which  could  be  used  within  the  class  context  to 
model  computer  systems.  The  class  effort  produced  the 
initial  program  design  and  two  program  modules.  The  CPMT 
development  task  was  then  the  topic  for  a  Master* s  Thesis  by 
LT  Karen  Pagel  [Ref.  2].  The  product  of  this  effort  was  an 
operational,  documented  and  partially  tested  simulation 
program  ready  to  be  used  as  a  classroom  tool  for  CS  4400, 
and  as  a  basis  for  further  development  and  enhancement. 

This  thesis  is  a  continuation  of  the  overall  CPMT 
development  project,  and  consists  of  an  adaptive  and 
perfective  maintenance  effort  to  modify  the  existing 
simulator  to  add  extended  modeling  capabilities  and  to 
enhance  the  simulator  performance. 

The  thesis  effort  also  included  rewriting  the  user's 
manual  to  reflect  new  features,  establishing  a  change  log 


foe  the  CPHT  program  and  continuing  validation  of  the 
simulator. 

B.  OBJECTIVES 

The  initial  CPHT  program  vas  operational  and  had  been 
used  as  part  of  a  class  exercise  for  CS  4400.  However,  from 
the  conclusions  listed  in  the  thesis  by  It  Pagel  [lef.  2], 
some  weaknesses  were  detected  by  program  designers  and  users 
which  justified  further  program  development.  From  those 
critics  and  analysis  cf  other  potential  improvements,  four 
major  types  of  requirements  were  identified  as  desirable 
areas  for  enhaceaent:  program  efficiency,  user 
friendliness,  modeling  capability,  and  simulation  run 
flexibility. 

The  objective  cf  this  thesis  vas  to  perform  a 
maintenance  effort  focused  on  the  areas  described  above, 
taking  advantage  of  the  readability  and  modularity  of  the 
original  CPMT  program  and  its  complete  documentation. 

C.  THESIS  OBGAIIZATIGI 

Chapter  2,  Haintenance  Effort,  describes  the  maintenance 
process  and  is  concerned  with  WHAT  and  WHY  maintenance  vas 
performed  on  the  CPHT  program.  It  discusses  limitations  of 
the  original  product  and  presents  the  additional 
requirements  and  program  enhancements  to  be  implemented 
through  the  maintenance  effort. 

Chapter  3,  Change  Log,  is  programming  oriented  and  is 
concerned  with  HOW  the  CPHT  program  vas  changed  and  which 
additional  requirements  have  been  implemented,  and  it 
includes  a  description  of  the  design  considerations  involved 
and  the  code  affected. 

The  new  version  of  the  CPHT  user’s  manual  is  provided  as 
Chapter  4  and  includes  a  description  and  examples  of  model 


design  and  an  explanation  of  how  the  prograa  is  con. 
Testing  and  validation  of  the  CPHT  prograa  are  discussed  in 
Chapter  5*  Hypothetical  coaputer  systeas  studies  have  been 
used  as  test  aodels  for  validation  of  the  siaulator. 

The  conclusions  in  Chapter  6  present  the  current 
liaitaticns  and  potential  enhancenents  for  continuing  the 
CPHT  prograa  develop aent. 


zi.  BjURHiiH  man 


1.  TIPI  Of  Bill  Till  KB 


Program  aaintenance  is  the  process  by  which  operational 
prograas  are  corrected,  adapted  or  upgraded.  Adaptive 
aaintenance  is  performed  to  modify  a  program  to  aeet  changes 
or  expansion  of  specifications.  Perfective  aaintenance  is 
performed  to  enhance  performance,  processing  efficiency  or 
maintainability  of  operational  programs.  Host  of  the 
aaintenance  work  produced  for  the  CPHT  program  focused  on 
adaptive  and  perfective  aaintenance  aspects.  Nevertheless, 
some  errors  in  the  original  program  were  discovered  and 
corrected  throughout  the  aaintenance  process. 

B.  H1I1TI11ICE  PBOCISS 

The  aaintenance  process  was  developed  through  the 
following  phases: 

•analysis  of  reguireaents 

•review  of  program  design 

•translation  of  new  design  into  code 

-testing 

•updating  of  documentation 

The  work  performed  during  these  phases  is  described  in 
the  following  sections. 


C.  1UL1SZS  OF  BSQUX1SIZ1TS 


The  purpose  of  the  first  step  of  the  maintenance  process 
was  to  identify  and  analyze  the  desirable  requirements  for 
the  si  salat  ion  program  and  to  group  then  according  to  the 
saintenance  work  involved. 

The  following  groups  of  requirements  have  been  analyzed: 

-  Improvement  of  processing  efficiency 

-  Extension  of  modeling  capabilities 

-  Improvement  of  simulation  run  flexibility 

-  Enhancement  of  program  user  friendliness 
1-  imaiSISBi  9l  processing 

Cne  important  decision  in  a  simulator  design  is  the 
computer  space  and  time  reguired  to  run  computer  system 
models.  In  the  original  CPHT  design,  all  job  and  event 
records  which  describe  the  problem  to  be  processed  by  the 
simulation  are  created  before  starting  to  process  jobs 
through  the  simulated  system.  After  all  jobs  are  processed, 
the  program  traverses  the  list  of  job  records  to  calculate 
the  job  statistics.  This  design  decision  leads  to 
inefficient  use  of  memory  space.  Long  simulations  are  not 
possible  on  the  original  program  due  to  large  memory  space 
requirements. 

In  the  new  version  jobs  and  events  are  dynamically 
created  as  the  simulation  is  being  processed  and  there  is 
only  a  single  event  record  attached  to  each  job  at  any  time. 
This  record  is  updated  whenever  a  new  event  for  that  job  is 
required*  Gathering  of  job  statistics  is  performed  as  jobs 
leave  the  system,  avoiding  long  lists,  and  allowing  job  and 
event  records  to  be  released  when  they  complete. 


2.  Extension  of  Modeling  Capabilities 
a.  Closed  Queueing  Networks 

One  of  the  major  advantages  of  simulation  is 
generality.  The  initial  version  of  the  CP/fT  program  can 
simulate  only  open  gueueing  network  models.  These  models 
often  are  appropriate  for  communication  system  modeling  and 
sometimes  for  computer  systems  modeling  [  Bef .  3  :p.  234]. 

Open  networks  are  characterized  by  one  source  of  job 
arrivals  and  one  sink  that  absorbs  jobs  departing  from  the 
network,  as  shown  in  fig  2. 1. 


One  of  the  implicit  assumptions  behind  these 
■odels  is  that  iaaediately  upon  its  arrival,  a  job  is 
scheduled  into  sain  aeaory  and  is  able  to  coapete  for 
resources  (Ref.  4  :  p.423].  In  practice  the  nuaber  of  aain 
aeaory  partitions  in  a  computer  systen  will  be  limited  which 
implies  the  existence  of  a  job  scheduler  queue.  For  a  large 
external  rate  of  arrival  of  jobs,  the  probability  that  there 
is  at  least  one  job  in  this  job  scheduler  queue  is  very 
hiqh,  and  it  nay  be  assuned  that  a  job  departure  iaaediately 
triggers  the  scheduling  of  an  already  waiting  job  into  aain 
aeaory.  This  situation  is  often  modeled  by  a  closed  queueing 
network,  which  acts  as  if  the  departing  jobs  wrap  around  to 
the  input,  and  iaaediately  re-enter  the  system.  This  type  of 
network  is  shown  in  Fig  2.2  • 

Each  circulating  job  is  an  active  job  and  must 
be  allocated  a  specific  partition  of  main  memory,  and  the 
total  number  of  active  jobs  is  called  the  degree  of 
multiprogramming.  Closed  queueing  network  models  have  been 
successfully  used  to  characterize  computer  systems  in  a 
multiprogramming  environment  £Bef.  3],  and  can  be  simulated 
in  the  new  CPHT  Simulator. 

b.  Alternative  Queueing  Disciplines 

A  queueing  discipline  is  an  algorithm  that 
determines  the  order  in  which  the  jobs  in  gueue  for  a 
servergroup  of  a  network  are  served.  A  weakness  of  the 
initial  version  of  the  simulator  is  that  no  provision  was 
aade  for  selection  of  the  queueing  discipline  to  be  assigned 
to  the  servers.  Jobs  are  always  served  in  a  first  coae  first 
served  basis.  This  aay  not  be  a  good  approximation  for  seme 
computer  systeas  in  which  other  queueing  disciplines  are 
implemented  is  order  to  improve  performance.  In  the  new 
version  of  the  simulator  the  following  additional  queueing 
disciplines  are  available  to  the  user,  and  can  be  assigned 
independently  to  any  servergroup. 


Figure  2.2  Closed  Queueing  Met work 


(1)  ££2££§§o£  Sfcatiai  (£S).  All  jobs 

simultaneously  receive  equal  shares  of  the  server.  This 
algorithm  is  used  to  model  the  effect  of  the  round  rotin 
gueueing  discipline  with  snail  quantum  and  overhead  tines. 

(2)  Monp£££&pti££  £ri0£itl  (HU)  -  dobs  are 

served  in  a  priority  basis  but  the  current  service  is  cot 
interrupted  if  a  higher  priority  job  arrives  at  the 

servezgroup. 

(3)  IISl  £2i£  £i£§l  £S£It  (k£JLS>  •  dels  are 

served  in  the  reverse  order  of  their  arrival. 

(4)  £££!£  In  fian^SJS  (2IR0).  Next  job  to 

he  served  is  chosen  probabilistically,  with  equal 
probabilities  assigned  to  all  queued  jobs. 


(5)  £&o£t  Processing  lias  Eitst  (S£X£) .  Jobs 
are  served  according  to  the  service  demand.  The  snail est 
service  reguest  is  served  first. 

(6)  Weighted  S&2I1  l£35&§£ i££  Tjje  First 

(WS£T£) .  Jobs  are  served  according  to  the 

deaand  and  priority.  The  job  with  the  saallest  reguest 
priority  ratio  is  served  first. 

c.  Measures  of  Perforaance 

Performance  parameters  such  as  systea  throughput 
and  average  nunber  of  jobs  in  the  systea  are  not  produced  by 
the  original  simulator. 

The  systea  throughput  is  defined  as  the  nunber 
of  jobs  processed  per  unit  of  tine.  Analysis  of  the  iapact 
of  CPU  service  disciplines,  level  of  programming  or  nunber 
of  processors  on  the  system  throughput  are  likely  to  be 
performed  in  the  development  and  design  of  computer  systems. 

The  mean  number  of  jobs  in  a  queueing  system  is 
expressed  analytically  in  terms  of  probabilities  and  random 
variables  as  described  in  LAVEMBEBG  [Bef.  1].  For  gueueing 
models  the  mean  nunber  of  jobs  in  the  systea  is  analytically 
described  by  eguation  2.1 
s 

E[n]=  1/sJ[nu]  du  (eqn  2.1) 

i+OP  o 

Computation  of  this  value  by  the  simulator  is  time  weighted 
through  the  simulation  run  as  described  in  Chapter  3. 

3-  imaisififti  Eaa  Eieiibiliii 

a.  Alternative  Methods  to  Specify  Simulation  Bun 

Duration 

One  characteristic  of  simulation  programs  is 
that  they  must  provide  the  timing  mechanism  for  the  system 


being  si aula ted.  i  list  of  cosing  events  is  generated  and 
ranked  according  to  time  of  occurrence.  The  simulator  tracks 
the  list  sad  cycles  through  the  following  steps: 

-  select  the  event  with  the  next  tiae 

-  set  the  clock  to  this  tine 

-  perform  action  according  to  the  type  of  occurrence 

Siaulation  run  duration  can  be  specified  by 
several  sethods.  The  easiest  approach  consists  of  specifying 
the  nuaber  of  tines  the  group  of  stateaents  which  perform 
the  steps  described  above  are  to  be  executed. 

Specification  of  the  number  of  jobs  tc  be 
processed  through  the  nodeled  system  is  an  alternative 
approach  and  was  chosen  by  the  original  program  designers. 
This  may  not  be  a  good  solution  for  closed  networks  where 
the  number  of  jobs  to  be  processed  is  not  clearly  defined. 
Another  disadvantage  of  this  approach  consists  of  the 
statistical  bias  introduced  by  the  shut-down  transition 
phase,  when  jobs  are  leaving  and  none  are  entering  the 
system.  Server  utilizations,  queue  lengths  and  response  tiae 
measurements  drop  in  that  phase,  affecting  the  final 
measurements  as  short  simulations  are  being  executed. 

The  most  usual  method  used  to  specify  run 
duration  consists  of  defining  the  total  time  of  the 
siaulation  run.  One  advantage  of  this  approach  is  to 
facilitate  simulator  validation,  by  allowing  comparisons 
between  simulation  results  and  system  accounting  data 
gathered  for  the  same  period  of  tiae. 

The  new  version  of  CPHT  program  provides  the 
options:  nuaber  of  jobs,  nuaber  of  events,  or  simulated  tiae 
as  specification  of  the  siaulation  run  duration  for  open 
networks,  and  the  last  two  alternatives  for  closed  gueueing 
networks. 


21 


b.  Rerunning  a  Simulation 

liter  producing  the  results  of  a  single 
simulation  run  the  new  version  of  CPHT  will  ask  whether  the 
user  wishes  to  run  the  simulation  again.  If  an  affirmative 
response  is  entered ,  user  will  be  allowed  to  enter  new 
values  for  the  simulation  run  specifications  and  rerun  the 
model  with  no  need  to  return  to  the  RASTER  MENU. 

c.  Specification  of  Period  of  Time  for  Statistics 

Statistical  bias  introduced  by  simulation 
execution  start-up  transition  (jobs  are  entering  and  none 
are  leaving)  and  shut-down  transition  (jobs  are  leaving  and 
none  are  entering)  is  significant  when  short  simulation  runs 
are  executed.  1  statistic  oriented  feature  was  implemented 
in  the  new  CPHT  versicn  to  reduce  or  eliminate  such  effects 
by  providing  a  special  option  to  the  user  to  specify  limits 
on  the  interval  of  time  for  gathering  statistics. 

4.  Enhancement  si  Oser  Friendliness 

Simulator  user  interface  is  a  concern  of  simulation 
program  designers.  If  it  is  difficult  to  interact  with  a 
program,  the  users  will  be  less  likely  to  use  it.  Oser 
friendliness  had  been  implemented  in  the  original  simulator, 
and  modifications  and  additions  were  accomplished  to  further 
improve  user  program  interaction. 

a.  Display  cf  Model  Specifications 

1  new  option  was  included  in  the  MAIN  HERO  to 
display  a  specified  data  base  record  for  a  given  simulation 
model,  making  possible  on-line  validation  of  input  model 
specifications. 
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t.  Printing  cf  Specifications  for  a  Single  Model 

In  additional  option  to  print  the  data  base  for 
a  single  aodel  was  implemented  to  improve  efficiency  and 
flexibility  in  accessing  data  base  infornation. 

c.  Updating  of  Model  Specifications 

Different  options  are  now  provided  to  handle 
user  reguests  depending  on  whether  there  is  already  an  user 
simulation  model  or  not.  If  a  simulation  model  already 
exists  in  the  data  base,  the  access  to  the  UPDATE  MENU  is 
given  from  the  HASTEN  MENU.  Otherwise,  the  option  to  enter 
the  new  simulation  aodel  number  will  display  the  model 
numbers  already  existing  in  data  base  to  prevent  collisions 
and  will  give  direct  access  to  the  UPDATE  MENU  as  a  new 
simulation  number  is  entered. 

d.  Copy  and  Deletion  of  Simulation  Models 

Options  to  copy  and  delete  simulation  models 
were  moved  from  the  UPDATE  MENU  to  the  MASTER  MENU.  The 
scope  of  the  main  options  in  the  new  version  is  defined  at 
the  simulation  model  level.  Updating  of  data  base  records  is 
accomplished  by  procedures  called  from  the  UPDATE  MENU 
rather  than  the  HASTEN  MENU. 

e.  Changing  of  Model  Specifications 

Modification  of  modeled  system  specifications  is 
likely  to  be  necessary  when  using  a  computer  system 
simulator.  Ho  option  to  change  aodel  specifications  was 
implemented  in  the  original  CPHT  simulation  program.  In  the 
new  version,  options  to  change  job  type  records,  routing 
records  and  servergroup  records  are  available  to  the  user, 
as  is  accessing  selected  items  within  records (  e.g.  job 
priority  within  a  job  type  record).  Contents  of  the  records 


before  and  after  changes  are  also  displayed  in  order  to 
facilitate  record  updating. 

f.  Facilities  for  Exception-handling 

&  goal  of  the  design  of  interactive  programs  is 
to  provide  facilities  for  exception-handling.  User  errors 
aust  be  expected,  and  the  user  should  not  be  adversely 
affected  by  then. 

The  CPMT  program  control  is  driven  either  by 
user  specification  cf  menu  options  or  user  response  to 
proapt  messages.  The  original  CPMT  version  does  not  accept 
an  alphabetic  character  as  a  response  for  requested  options. 
In  such  case  the  prograa  will  abort  and  the  user  has  to 
restart  again.  In  the  new  version  this  will  be  interpreted 
as  an  invalid  option,  and  the  aenu  will  be  displayed  again. 

The  convention  of  requiring  the  uppercase  '¥* 
for  a  *yes*  response  was  also  eliainated  for  the  revised 
prograa.  Both  upper  and  lover  case  of  the  lettee  are  assuaed 
to  be  the  affiraative  response. 

Soae  input  validation  is  performed  by  the 
original  prograa,  to  insure  that  input  values  are  within 
bounds  set  by  either  prograa  specification  (e.  g.  menu 
options)  or  siaulation  specification  (e.g.  mean  service 
tiae)  .  Additional  input  validation  is  accomplished  by  the 
new  version  to  prevent  abnormal  prograa  termination. 

g.  Printing  cf  Specifications 

Distribution  types  and  queueing  disciplines  are 
printed  on  the  screen  and  written  to  output  files  as 
aeaningful  data  rather  than  nunerical  values,  to  iaprcve 
readability  of  prograa  output. 
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0.  BEVIEV  OP  PBOGBlfl  DESISH  AHD  I BPLEBE1TATI0B 


For  design  and  i spies ent at ion  of  changes,  a  schedule  was 
established  according  to  the  following  priority  basis: 

-  Simulator  nodeling  capability 

-  Program  efficiency 

-  Siaulation  run  flexibility 

-  Prograa  user  friendliness 

The  baseline  for  design  solutions  was  to  minimize  the 
impact  of  changes  cn  the  program  modularity  and  data 
structures.  The  algorithms  and  implementation  considerations 
are  described  in  Chapter  3. 

E.  TESTI1G 

Program  testing  was  performed  throughout  the  change 
implementation.  A  few  errors  were  found  in  the  original 
program  and  fixed  during  testing  activity.  Verification  of 
prograa  correctness  under  new  processing  efficiency 
requirements  was  performed  by  comparison  of  the  execution  of 
the  new  program  with  the  execution  of  the  original  program, 
followed  by  analysis  of  results.  The  quality  of  the  program 
as  a  simulation  tool  is  discussed  in  Chapters  5  and  6. 

F.  UPDATIHG  OF  D0CUBZETATI01 

Technical  and  user  documentation  was  updated  to  reflect 
changes  in  prograa  code  and  simulator  operation.  In  addition 
to  rewriting  the  comments  in  the  listing  file,  a  change  log 
was  created  to  facilitate  further  program  maintenance.  The 
change  log  and  the  new  version  of  the  CPMT  user's  manual  are 
presented  in  the  next  two  chapters  of  this  thesis. 
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III.  C HAIGS  LOG 


Is  order  to  provide  information  necessary  to  understand 
the  current  aodifications  and  trace  the  evolution  of  the 
CPHT  program  froa  the  initial  configuration,  a  change  log 
was  created.  This  chapter  suaaarizes  and  presents  the 
contents  of  the  log.  Entries  to  the  log  include  the 
following  information,  if  applicable  : 

-  Change  number 

-  Type  of  maintenance  (Corrective, adaptive  or  perfective) 

-  Type  of  requirement 

-  Brief  descripticn  of  requirement  or  anomaly 

-  Change  design 

-  Changes  in  records  and  data  items 

-  Files  affected 

-  Modules  affected 

-  Procedure  and/or  Functions  eliminated  or  changed 

-  Hew  procedures  and/or  Functions 

-  Explanation 

-  Impact  on  the  pregram  modularity, clarity  etc. 

Changes  implemented  as  a  result  of  this  thesis  effort 
are  described  in  the  next  sections,  grouped  by  type  of 
maintenance  and  classification  of  requirements  as  described 
in  Chapter  2.  Change  numbers  were  sequentially  assigned  for 
easier  reference.  Statistics  about  the  type  and  volume  of 


maintenance  are  presented  in  the  last  section  of  this 
chapter. 

1.  P INFECTIVE  CHUG  IS 

1.  IsAgfiiiaa  fi£  Eeaorv  Beg^ireaents 
a.  CHANGE  *1 
t.  Change  Design 

Dynamic  creation  and  allocation  of  job  and  event 
records  as  a  simulation  is  being  processed. 

c.  Change  Dictionary 

Itens  NEXT_SERV  and  COMPLETE  were  created  for 
the  JOB  TYPE  RECORD ,  to  identify  the  servergroup  at  which 
the  next  processing  event  will  tale  place,  and  detect  the 
job  completion;  the  item  FIRST_JOB_PART  of  the  same  record 
was  eliminated;  itens  NEXT_JOB_P ART  and  SCHEDULED  were 
eliminated  from  the  EVENT  RECORD. 

d.  Files  Affected 

CEET.  PAS 
CJS.PAS 
EXT. PAS 

e.  Nodules  Affected 

CREATE  JOB  STREAH 
EXECUTE  AND  TABULATE 

f.  Procedure  Eliminated 

CREATE  JOB  STREAM 


g.  Procedures  Changed 
CBEATE_JOB 

BXICUTE_AHDJTABDLATE 
D£PABT_FBOH_SG 
JCE_ABBIVAL 
JOB_COHPLETED 
ABBIV E_AT_SG 

h.  New  Procedures 

FISD_JOB_TYPE 
CBIATE_IHITIAI_JOBS 
CBEATE_HE»_EYEHT 
EXECUTE 

i.  Explanaticn 

There  is  no  job  streas  in  the  new  design,  thus 
the  procedure  Cfi EA TE_ JOB_ STB EA 9  was  elisinated.  The  nase  of 
the  respective  nodule  was  not  nodified  for  easier  reference. 
The  new  input  for  the  EXECUT E_AND_TABULATE  nodule  is  the 
linked  list  of  job  records  created  by  the  new  procedure 
CBE ATE_IHITIAL_JOBS ,  and  consists  of  one  job  of  each  job 
type  of  the  sinulated  nodel.  Each  job  record  is  created  by 
the  nodified  procedure  CBEATE_JOB,  and  has  only  one 
associated  EVEHT  record  which  stores  the  inforaation 
required  for  the  first  event  of  that  job.  Creation  of  events 
during  a  siaulation  run  is  requested  fron  the  procedure 
EXECUTE_AHD_TABULATE  as  a  job  departs  fron  a  servergroup. 

Creation  of  jobs  during  a  simulation  run  depends 
on  the  type  of  network  being  sinulated.  For  the  original 
progran  capability,  open  networks,  the  process  is  as 
follows:  as  a  job  arrives  to  the  servergroup  0  (dummy 

server) ,the  procedure  JOB_AFBIVAL  invokes  first  the  new 
procedure  FIHD  JOB  TYPE  in  order  to  access  in  the  data  base 


the  JCB  TYPE  record  vith  the  saae  job  type,  and  then  calls 
the  procedure  CBEATE_JOB  to  create  a  new  job.  Allocation  of 
job  aad  event  records  for  the  new  job  depends  on  whether 
there  are  records  available  or  not.  As  a  job  coapletes,  the 
job  type  record  is  referenced  by  a  pointer,  and  a  flag  is 
set  to  notify  the  procedure  CBEATE.JOB  that  there  is  no  need 
to  allocate  new  records.  In  this  case,  the  CBEATE_JOB 
procedure  updates  the  job  and  event  records  for  the  new  job. 
Otherwise,  new  job  and  event  records  will  be  allocated.  The 
arrival  tiae  of  the  new  job  is  coaputed  as  the  arrival  tiae 
of  the  arrived  job  plus  the  interarrival  tiae  calculated  in 
the  procedure  CREATE_JOB.  The  job  record  is  attached  to  the 
arrival  gueue  for  the  servergroup  0  and  becoaes  ready  to  be 
processed.  A  counter  is  increaented  to  Jceep  track  of  the 
nuaber  of  jobs  processed. 

As  referenced  above,  there  is  a  single  event 
record  associated  with  each  job  record.  That  record  is 
updated  by  the  new  procedure  CREATE_NEH_EVEMT  which  is 
called  by  the  procedure  DEPAHT_FROH_SG.  As  a  job  departs 
froa  a  servergroup,  the  nuaber  of  the  next  servergroup  to 
which  the  job  is  routed  is  checked.  If  that  servergroup  is 
not  the  exit  servergroup  (SG10)  a  new  event  is  created  for 
that  job. 

A  new  procedure  EXECUTE  was  created  within  the 
procedure  EXECUT£_AND_TABULATE  for  easier  prcgraa 
readability.  This  procedure  handles  the  processing  loop  of 
job  departures  and  arrivals  and  calls  the  procedures 
DEPABT_FBOM— SG  and  ARBIVE_AT_SG. 

j.  Iapact  on  the  Prograa  Modularity 

Program  nodularity  was  affected  by  this  change. 
Procedures  CBEATE_JCE,  CHEAT E_HEiEVENT  and  FIND_JOB_TYPE 
froa  the  aodule  CREATE  JOB  STREAM  are  called  by  procedures 
froa  the  EXECUTE  AND  TABULATE  aodule. 


2.  figflggtigft  s£  Essgsagira  ins  is  Eisflass 


a.  CHANGE  *2 

b.  Change  Design 

There  is  no  longer  a  need  to  traverse  a  linked 
list  of  job  records  for  gathering  statistics;  infornation  is 
collected  as  jobs  coajlete.  Standard  deviation  computations 
in  the  nev  design  are  calculated  by  a  different  algoritha 
that  is  described  in  the  change  explanation. 

c.  File  Affected 

EXT. PAS 

d.  Module  Affected 

EXEC DTE  AND  TABULATE 

e.  Procedures  Elininated 

STDJJEV 

SirjJEV.JOBJTYPBS 

f.  Procedures  Changed 

JCE_COHPLETED 

STATS_FOB_JOBS 

ST1TS_F0B_J0BJTIPES 

g.  Nev  Procedure 

INITIALIZE..  ST  ATS 

h.  Explanation 

A  nev  procedure  INITIALIZE.STATS  was  created  to 
initialize  the  statistical  counters  and  accuiulator 
variables. 


As  each  job  completes,  the  values  of  the 
statistical  counters  and  accumulator  variables  are  updated; 
as  the  processing  of  jobs  is  completed,  procedures 
STATS_F01_J0BS  and  STATS^POR.JOBJTYPES  compute  and  print 
statistics  for  all  the  jobs  and  for  each  job  type. 

For  computation  of  standard  deviations  let  T  be 
defined  by  eguation  3.1  : 

N 

T  BEAN  )*  (eqn  3-1) 

Using  binomial  theorem  in  eguation  3.1  ,  T  can  be  expressed 
as: 

N  N 

T  -El.*  -  2*HEAMaHxi+  H*«EAH*  (egn  3.2) 

;»c  v  i~  i 

N 

BEAB  ■J^X-y  H  (egn  3.3) 

l 

N 

Substituting Y*X;  from  equation  3.3  and  simplifying  eguation 
3.2  ,  T  can  be  defined  as: 

N 

T  *ZIXf  -  H*HEAN*  (eqn  3.4) 

N 

VARIANCE  KAN)  *  /  H  (eqn  3.5) 

v-/ 

STANDARD  DEVIATION  «  V«EAN  (eqn  3.6) 

Using  equations  3.4  ,  3.5  and  3.6  ,  STANDARD  DEVIATION  can 

be  expressed  by  the  following  eguation  : 

\j - 7J - 

STANDABD  DBF  «  |  |  51  X*  -  N*HEAH2) /N  (eqn  3.7) 

i«i  ‘ 

Based  on  egs  3.3,  3.4  and  3.7  the  following  algoritha  was 

implemented: 


— -  It  the  ith  job  completion  compute  the 
square  of  the  current  variable  Z  and  update 
the  statistical  accumulator  X? 


-  Is  the  processing  of  jobs  is  finished 

(Nth  job  completion)  ,  compute  the  values  of 
the  HUH,  T  and  STANDABD  DEVIATION. 

B.  ADAPTIVE  CHA1GES 

i.  capability  Isl  Claas4  fla sasiaa  laiigJLls  ttgflaUM 

a.  CHANGE  *3 
t.  Change  Design 

Dynamic  creation  of  jobs  is  accomplished  by  two 
distinct  methods  whether  the  model  being  simulated  is  an 
open  or  closed  network.  For  open  networks,  as  described  in 
change  #1,  the  linked  list  of  jobs  created  by  the  procedure 
CBEAT£_INITIAL_JOBS  consists  of  one  job  for  each  job  type. 
If  a  closed  network  is  being  simulated  the  number  of  jobs 
for  each  type  created  by  the  CHEATB_INITIAL_JOBS  procedure 
depends  on  the  model  specification  and  is  deteained  by  the 
level  of  prcgraaming  for  each  job  type.  Furthermore,  for 
closed  network  modeling,  a  job  completion  will  force  the 
arrival  of  an  identical  job  into  the  system. 

c.  Files  Affected 

CJS.PAS 

OEEOD.PAS 


a.  Modules  Affected 


CREATE  JOB  STREAM 
0  PLATE 

EXECUTE  AID  TABOLATE 
HA1H  DRIVES 

e.  Procedures  changed 

ADD_JOB_TYPE 

EXECOTEJkHDjrABOLATE 

DEPART_PROM_SG 

JCE_ARRIVA1 

JOB_COMPLETED 

f.  New  Procedure 

CHECK^HETjrYPE 

g.  Explanation 

The  program  processes  jobs  according  tc  the 
sieulation  nuaber  assigned  to  the  aodeled  system.  A  new 
procedure  CHBCK_BBT  JTYPE  returns  the  value  of  a  boolean 
variable  deterained  by  the  siaulation  model  number  used  as 
input.  Siaulation  models  1  through  49  are  assigned  to  open 
networks  and  50  through  100  to  closed  network  aodeling. 

These  ranges  can  be  easily  changed  by  aodifying 
the  bound  assigned  in  the  procedure  CHECK_NET_TYPE 

For  closed  networks  the  arrival  time  assigned  to 
job  records  is  not  dependent  on  the  user  specifications,  but 
rather  determined  by  the  procedure  which  drives  the  creation 
of  the  new  job.  For  jobs  created  by  the  procedure 
CREATI_I8ITIAL_JOBS  the  arrival  time  is  one  1  ,  otherwise 
(jobs  created  by  the  procedure  J0B_C0MPLETE)  the  arrival 


'The  deterministic  and  short  interarrival  time  was 
ghosen  by  the  program  designer  to  reduce  the  elapsed  time  to 
initialize  the  closed  network 


tiae  for  the  new  jot  will  be  the  tiae  the  coapleted  job 
leaves  the  systea.  1  flag  is  set  at  each  job  coapleticn  to 
define  the  instant  a  nev  job  has  to  be  scheduled.  The 
procedure  DEPABT_FBOH_SG  will  force  a  new  event  that  will  be 
a  departure  froa  the  servergroup  0. 


;ive  Queueing  Disciplines 


2.  gap  ability  £sx  AH 

a.  CHANGE  #4 
t.  Change  Design 


The  queueing  discipline  to  be  observed  at  a 
given  servergroup  is  specified  by  the  user  as  he  is  adding 
routing  records  to  a  job  type.  Bhenever  a  job  arrives  to  a 
servergroup  that  has  a  waiting  queue,  it  is  inserted 
according  to  the  queueing  discipline  specified  for  that 
servergrcup. 

c.  Change  Dictionary 

Nev  iteas  REC_DI  SC  and  Q_DISC  were  included 
respectively  in  the  DATA  BASE  and  S SEVER  records  to  identify 
the  queueing  discipline  assigned  to  the  servergroup. 

d.  Files  Affected 

RICFILE.  DAT 
E IT. PAS 
C BBT. PAS 

e.  Modules  Affected 


UPDATE 

EXECUTE  AND  TABULATE 


f.  procedures  Changed 


ADD_ROOTIHG_RECORD 
IC_ED IT 
PRINTER 

B0I1D—LL_FB  Cfl_DB 
PBOCESS_BOOTIHG_DATA 
E  X  ECOT  E_A  ND_T  ABB  L  AT  E 
CBEATE_SEBVER_GBOOPS 
ABBIVE_AT_SG 
DEPABT_FROH_SG 
IBSEBT_m_SG_Q 
ATTACH_JOB_TO_SEBVEB 

g.  New  Procedures 

SG_Q_INSEHTJFBONT 
SG_Q_INSERT_PRIOBITY 
S  G_Q_INS  ERT_PROC_TIH  E 
SG_Q_IBSERT_NEIGHT 
S’G_Q_IBSERT_BANDOI! 

h.  Ezplanaticn 

The  gueueing  discipline  assigned  to  a 
servergroup  is  stored  in  the  database  as  the  user  adds 
routing  records  to  a  job  type  record.  As  the  linked  list  for 
routing  jobs  is  created  (procedure  CREATE_ROUTING_RECORD)  , 
the  values  of  the  gueueing  disciplines  are  stored  in  a  one 
diaensional  array.  The  procedure  CREATE_SERVER_GROOPS  reads 
frou  that  array  the  discipline  that  is  to  be  assigned  to 
each  servergroup,  and  stores  it  into  the  respective 
servergreup  record. 

I 

The  selection  of  procedures  for  inpleaentation 
of  the  scheduling  algorithm  to  be  observed  at  a  servergroup 
is  performed  by  the  procedure  INSEBT_IH_SG. 


The  procedures  to  iapleaeat  the  Last  Coae  First 
Served  (1CFS) ,  Nonpreeaptive  Priority  (NP)  ,  Lowest 
Processing  Tiae  First  (LPTF)  ,  and  Lowest  weighted  Processing 
Tine  First  (LHPTF)  algorithas  are  self  explanatory. 

Siaulation  of  randoa  service  is  accoaplished  by 
randoa  insertion  of  jobs  in  the  waiting  gueue;  the  position 
in  which  a  job  is  inserted  is  coaputed  froa  the  function 
GENEBATE_VA1UE ,  using  the  nuaber  of  gueued  jobs  that  is 
stored  in  the  servergroup  record. 

The  PEOCESSOB  SHARED  iapleaent ation  is  based  on 
the  algoritha  described  in  SAUER  and  CHANDX  [Ref.  4  :p.200], 
and  it  is  distributed  across  the  procedures 
SG_Q_INSEBT_PBOCJFIHI,  A TTACH_JOB_TO— SERVER ,  and 
INSERT_ IN_SG_Q.  The  job  with  the  saallest  processing  tiae 
aust  be  the  first  to  leave  the  gueue  and  so, the  saallest 
processing  tiae  first  algoritha  is  used  for  insertion  into 
the  waiting  gueue.  Ccaputation  of  the  service  tiae  depends 
on  the  nuaber  of  jobs  waiting  to  be  served  and  is  egual  to 
that  nuaber  tiaes  the  reguest  tiae  of  the  current  job  being 
served.  When  the  job  coapletes  service,  that  aaount  of  tiae 
is  subtracted  froa  the  reguest  of  each  job  in  the  gueue,  if 
any,  to  obtain  the  job  reaaining  reguests. 

i.  Iapact  on  the  Prograa  Nodularity 

The  procedure  INSERT_IN_SG_Q  in  the  EXECUTE  AND 
TABULATE  aodule  calls  the  function  GEN  ERATE_.fi  ANDOH_ VALUE 
outside  the  aodule,  to  generate  a  randoa  position  for 
insertion  into  the  waiting  gueue. 

3.  Coaputation  of  th§  Been  Nuaber  of  Jobs  in  tfee  Svstea 
a.  CHANGE  *5 
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t.  Change  Design 

The  al gorithn  for  a  tine  weighted  computation  of 
the  nunber  of  jobs  in  the  system  is  described  in  the  change 
explanation. 

c.  File  Affected 

EXT. PAS 

d.  Ho  dole  Affected 

EXECUTE  AND  TABULATE 

e.  Procedures  Changed 

J  CE_AREIYA1 
JOB— COMPLETED 
STATS_FOR_JCBS 
S1ATS_F0R_J0B_TTPBS 

f.  Explanation 

As  illustrated  in  Figure  3. 1  the  value  of  the 
oean  nunber  of  jobs  depends  on  the  tine  accumulated  value  of 
the  area  under  the  ccrve,  A„.  The  value  of  Anat  the  instant 
t^is  confuted  fron  eguation  3.8  where  t£  is  the  tine  of  a 
job  arrival  or  departure,  and  NiM  is  the  nunber  of  jots  in 
the  systen  at  tine  t;_,. 

The  algorithn  used  for  conputation  of  the  mean 
nunber  of  jobs  in  the  systen  was  implemented  for  all  jobs 
and  for  each  individual  job  type.  Computation  of  the  value 
of  An  at  a  given  tine  is  perforned  either  by  the  procedure 
JOB_ARBIVAL  or  J CB_C C SPL ET ED  depending  on  if  the  event  is  an 
arrival  to  the  systen  or  a  job  completion.  The  nunber  of 
jobs  in  the  systen  at  tines  t^and  tiMare  stored  in  the  array 
T07AL_J0BS_SYS,  and  the  values  of  tj  and  t^,  are  stored  in  the 
array  INTEREYENT.  As  the  value  of  A ;  is  calculated,  the 


Figure  3*1  Bean  lumber  of  Jobs  in  the  System 


-  E  (‘i  »*» 


(egn  3.8) 


values  of  and  t;_, ,  which  are  no  longer  reyuirei,  are 
replaced  by  the  values  Nj  and  1 1  to  prepare  for  the  next 
computation.  The  example  shown  in  Figure  3.2  illustrates 
the  application  of  the  algorithm. 

The  last  step,  which  computes  the  mean  value, 
consists  of  dividing  the  accumulated  area  by  the  simulation 
time.  This  step  is  performed  by  the  procedures 
STATS^FOR_JOBS  and  STATS  FOR  JCB  TYPES. 


1)  Initial  data 


t  = 

50 

INTEBEYENT  (0) 

=  50 

N  = 

4 

IHTEBEYENT(lf 
TOTAL  JOBS  SYS  (0) 

=  ** 
i  =  4 

ABEA 

=  12 

TOTAL“JOBS”SYS  (1 

,  =  ** 

At 

time  55 

occurs  a  job  departure 

t 

=  55 

INTEBEVEHT  (0) 

=  50 

INTEBEYENT { 1) 

=  55 

N 

=  3 

TOTAL  JOBS  SYS (0 

)  *  4 

TOTAL” JO BS~SYS ( 1 

)  =  3 

3)  Computation  of  the  nev  ABEA  at  tine  55 
ABBA  =  ABEA  ♦ 

TOT  AL_ JO  BS_S  YS  (0  )  *  ( I HT  EB BY  EH  T  { 1 )  -  INTEBEY  BN T  {  0)  ) 
ABEA  =  12  ♦  4  *  (  55  -  50  ) 

ABEA  *  32 

4)  Preparation  for  the  next  computation 


INTEBEYENT  (0) 

s 

55 

INTEBEYENT  (li 

s 

** 

TOTAL  JOBS  SYS (0 

)  = 

3 

TOTAL”JOBS”SYS(1 

J  = 

** 

I _ 

Figure  3.2  Computation  of  the  Accumulated  Area 


4 .  Interval  for  Gathering  Statistics 

a.  CHANGE  16 

b.  Change  Design 

Updating  of  the  job  and  servergroup  records  as  a 
simulation  is  being  processed  is  performed  over  a  period  of 
time  specified  by  the  user. 


Files  Affected 


Cl FT. PAS 


EXT. PAS 
MESSAGES.  DAT 


Modules  Affected 


HAIM  DRIVES 


EXECUTE  AMD  TABULATE 


e.  Procedures  Changed 

S1ATS_FOR_JOBS 

STATS_FOE-,JOB_TXPES 

SIATS_FORJSERVERGROUPS 

JCE— ARRIVAL 

JOE_IH.SG._Q 

HC_JOB_IH_SG_Q 

JGB.COHP LET ED 

ATTACH.JOB.TO.SERVER 

AI1ACH_FIRST_IN_Q 

IHSERT.IH.SG.Q 

f.  Explanation 

Gathering  of  information  frou  job  and 
servergroup  records  to  produce  statistics  is  performed 
depending  on  whether  a  flag  is  set  or  not.  The  flag  is 
inplenented  by  the  boolean  variable  STATS  and  its  value 
depends  on  the  siaulation  run  specifications  selected  by  the 
user,  as  shown  in  the  diagram  of  Figure  3. 3  . 

As  the  siaulator  timing  mechanism  is  driven  by 
events,  the  specification  of  the  interval  for  gathering 
statistics  introduces  the  need  of  a  correction  in  the 
computation  of  the  number  of  jobs  in  the  system,  as 
illustrated  in  Figure  3.4. 


OS  EB 
SPEC 

IHTEBVAL 

v  ? 


STATS  =  TROE 


/Input 
start  tine 
stop  tiae 


'  is  X. 
C1K  >=  starl 
C1K  >-  stop 
v  *?  y 


STATS  =  FALSE 


STATS  =  TRUE 


Figure  3.3  Value  of  the  Statistical  Flag 


As  statistics  start  up  and  shut  down,  the  areas 
A1  and  A2  are  calculated  at  the  ocurrence  of  events  t&  and  t( 
,  using  equations  3.9  and  3.10  where  Sa  and  Nc  are  the 
nuaber  of  jobs  in  the  systea  at  tines  ta  and  tc .  Coaputation 
of  areas  A1  and  A2  and  respective  suaaation  to  the  total 
accunulated  area  A  are  perforaed  either  by  the  procedure 
JOB_ARRIVAL  or  J0B_CCHPLETE0  depending  on  whether  the  events 
t  and  t  are  job  arrivals  to  the  systea  or  job  coapletions. 


Figure  3.4  Start  and  Stop  Areas 

A1  =  [tb  -  start_stats)  ♦  (egn  3.9) 

A2  =  (stop_stats  -  tc  )  *  Nc  (egn  3.  10) 

5«  cf  t£e  Ihyougftpufc 

a.  CHANGE  *7 
t.  Change  Design 

Accounting  of  the  nuaber  of  job  completions  for 
all  jobs  and  by  individual  job  type;  division  of  those 
numbers  by  the  elapsed  tiae  to  determine  the  rate  of 
throughput. 


c.  File  Affected 


EXT. PAS 

d.  Rodale  Affected 

EXEC DTE  AND  TABULATE 

e.  Procedures  Changed 

JOB.COHPLETED 

STATS_FOB_JOBS 

SIATS_FOB_JOB_TYP£S 

f.  Explanation 

Statistical  counters  in  the  procedure 
JOB.CCHP1ETED  keep  accumulating  the  number  of  job 
completions  as  the  simulation  is  being  processed.  The 
procedures  STAT— FOB_JCBS  and  STATS_FOR_JOB_TYPES  compute  the 
throughput  values,  by  dividing  the  total  number  of 
completions  by  the  siculated  time. 

6.  Alternative  Specification  of  Bun  Duration 
a.  CHANGE  *8 
h.  Change  Design 

When  a  simulation  run  is  to  be  processed,  the 
user  specifies  the  option  for  run  duration.  The  option  is 
either  to  end  the  simulation  after  a  specified  number  of 
events  or  after  a  specified  simulation  time.  Different 
conditions  are  set  for  controlling  the  number  of  iterations 
of  the  processing  loop  depending  on  the  choice. 

c.  File  Affected 

EXT. PAS 
CIKT.  PAS 


d.  Modules  Iff ec ted 


EXECUTE  AND  TABULATE 

|  MAIN  DBIVEB 

e.  Procedures  Changed 

EX£COTE_AND_TABOLATE 

|  JOE_ABHI VAL 

f.  Explanation 

In  the  original  progran  the  run  duration  is 
|  always  defined  hy  the  number  of  jobs  to  be  processed,  and 

the  execution  of  the  aain  processing  loop  in  the  procedure 
EX  EC  0  TE_ AN  D_T ABU LAT E  terminates  when  there  are  no  pending 
events  to  be  processed  in  the  servergroups.  The  alternative 
|  conditions  created  for  controlling  the  processing  loop  are 

enabled  by  the  user  specification  of  either  the  nunber  of 
events  or  sinulation  tine.  In  such  cases  the  variables  to  be 
checked  by  the  processing  loop  will  be  either  a  counter 
j  placed  inside  the  loop  or  the  clock.  The  case  structures  on 

the  aain  driver  select  the  control  of  the  processing  loop 
according  to  the  type  of  network  and  user  specification  of 
the  run  duration. 

|  If  the  run  duration  is  specified  by  simulated 

tine,  and  no  interval  for  statistics  was  defined,  a 
correction  has  to  be  done  for  conputation  of  the  average 
nunber  of  jobs  in  the  systea.  As  the  siaulator  timing 
aechanisa  is  actually  controlled  by  the  occurrence  of 
events,  the  execution  of  the  processing  loop  terainates  at 
the  event  which  occurs  closest  to  the  specified  sinulated 
tine,  see  Figure  3.5  .  As  the  conputation  of  the  mean 

nuaber  of  jobs  is  tiae  weighted,  as  explained  in  Change  *5, 
the  last  area  to  be  accunulated  in  this  case  is  calculated 
froa  eguation  3.11  where  t £  is  the  last  event  processed 
before  the  siaulation  tine  is  over. 


i  *  (simulated_tiae  -  t* )  *  H| 


(egn  3.  11) 


Figure  3.5  Correction  of  the  Accumulated  Area 

This  computation  is  performed  by  the  procedure 
STATS__FCE_J03S  for  all  jots  and  by  th«  procedure 

STATS_FOB_JOB_TYPES  for  each  job  type. 

7.  Capability  Iqi  fiergpnipa  £  SlSMldtifin 

a.  CHANGE  *9 

t.  Change  Design 

The  program  cycles  through  the  simulation 

execution  code  under  user  control. 

c.  File  affected 


CPHT.PAS 


a.  Module  affected 


Main  Driver 
e.  Explanation 

When  a  acdel  specification  is  correct,  it  can  be 
repeatedly  executed.  The  condition  for  loop  termination  is 
set  by  the  user  response  to  a  prompt  message. 

8.  EisEiai  q£  Model  Specifications 
a.  CHANGE  *10 
t.  Change  Design 

An  additional  option  was  included  in  the  MASTER 
MEMO  and  a  new  procedure  was  created  for  printing  single 
data  base  records  on  the  screen. 

c.  Files  affected 

DIEOD.PAS 
CPMT.PAS 
MESSAGES. DAT 

d.  Modules  affected 

UPDATE 
MAIM  DRIVER 

e.  Mew  procedure 

DISPLAI.HODEL 

f.  Explanation 

The  new  procedure  DISPLAI.MODEL  was  placed 
within  the  UPDATE  module  and  is  called  from  the  case 
construct  implemented  in  the  main  driver.  It  first  attempts 
to  locate  the  simulation  model  in  the  data  base  by  the 


record  key  computed  from  the  entered  siaulation  aodel 
nuaber.  If  the  key  is  not  found  an  error  message  is 
presented,  otherwise  the  record  type  and  nuaber  will  be 
proapted  for.  In  this  case  the  procedure  atteapts  to  locate 
the  selected  record  in  the  data  base;  if  the  record  key  is 
found  the  record  contents  are  displayed,  otherwise  an  error 
aessage  will  be  produced.  The  procedure  cycles  through  these 
steps  if  the  user  desires. 

9.  Hinting  Ql  JJfldei  Spec jjjgat A-Q&§ 
a.  CHANGE  *11 
t.  Change  Design 

An  additional  option  was  included  in  the  HASTER 
HENO  and  a  new  procedure  was  created  for  printing  all 
records  of  a  siaulaticn  aodel  to  the  output  file. 

c.  Files  Affected 

DEHOD. PA S 

CEBT.PAS 

HESSAGES.DAT 

d.  Modules  Affected 

UPDATE 
HAIR  DRIVER 

e.  New  Procedure 

PBINT_DATA_EASE_HODEL 

f.  Explanation 

The  new  procedure  PRINT_DATA_BASE_model  is 
called  froa  the  Main  Driver  and  first  attempts  to  locate  the 
siaulaticn  aodel  by  the  key  coaputed  froa  the  entered 
siaulation  model  number.  If  the  record  key  is  not  found  an 


error  message  is  displayed,  otherwise  all  the  records  for 
that  siaulation  aodel  will  be  printed  to  the  file  OUTFILE. 

10.  sedaUfig  2l  Jte£sl  Seesilisatiaas 

a.  .CHANGE  #  12 

b.  Change  Design 

Updating  of  the  data  base  in  the  original 
progras  design  is  processed  by  first  selecting  the  option 
froa  the  HASTES  HEN 0  to  update  the  data  base,  and  then 
entering  the  siaulation  aodel  number.  If  an  already  existing 
siaulation  aodel  nuaber  is  entered  by  the  user,  the  program 
produces  an  error  message,  otherwise  the  UPDATE  HENU  is 
displayed. 

The  new  version  has  a  special  option  in  the 
HASTES  HENU  to  enter  a  new  siaulation  aodel  number,  which 
will  display  a  list  of  the  siaulation  numbers  already 
existing  in  the  data  base;  as  the  user  enters  a  new 
siaulation  aodel  nuaber  the  UPDATE  HENU  is  automatically 
displayed  and  the  program  becoaes  ready  for  record  updating. 

The  update  option  in  the  HASTES  HENU  is  to  be 
selected  if  a  user  already  has  siaulation  models  in  the  data 
base. 


c.  Files  Affected 

UFEOD. PAS 
CFHT.PAS 
MESSAGES. DAT 

d.  Modules  Affected 


U  PEATS 
HAIN  DRIVES 


e.  Procedures  Changed 

E1TER_SIH_HUM 
UPDATE  JIENU 

£.  New  Procedure 

PRINT_SIM_NUM 

g.  Explanation 

The  modified  procedure  ENTER_SIM_HUH  is  called 
froa  the  HAIM  DRIVER  rather  than  fron  the  procedure 

0PDATE_HEHU,  if  the  options  "enter  new  simulation  number"  or 
"updating  of  model  specifications"  are  selected  by  the  user. 
If  the  first  option  is  chosen,  the  new  procedure 

PBIHT__SIM_HUM  will  be  called  to  search  for  the  existing 
models  and  display  their  numbers  on  the  screen.  If  the  data 
base  is  empty  an  appropriate  message  will  be  displayed.  In 
both  options,  but  for  different  reasons,  the  procedure 
EHTER_SIH_MOM  checks  for  a  repeating  key  before  giving 
access  to  the  UPDATE  MENU.  Appropriate  messages  will  be 
displayed  for  the  case  of  entering  a  repeated  simulation 
number  as  a  new  number,  or  trying  to  update  a  nonexisting 
simulation  model. 

11.  Deletion  and  Copy  of  simulation  Hodel 

a.  CHANGE  113 

b.  Change  Design 

In  the  new  design,  as  described  in  Chapter  2, 
the  scope  of  the  main  options  is  defined  at  the  simulation 
model  level  and  so  copy  and  deletion  of  simulation  models 
are  options  from  the  MASTER  MENU  rather  than  from  the  UPDATE 


c.  Files  Affected 

UPHOD. PAS 
CPET.  PAS 
MESSAGES. DAT 

d.  Modules  Affected 

UPDATE 
MAIM  DRIVER 

e.  Procedure  Changed 

U PEAT E_H EMU 

f.  Explanation 

The  procedures  DEL_SIE_MODEL  and  COPY_SIM_HODEL  for  deletion 
and  copy  of  aodel  records  froa  the  data  base  were  noved 
outside  of  the  procedure  UPDATE_MENU  and  are  called  froa  the 
case  structure  iapleaented  in  the  aain  driver. 

12.  Changing  of  the  Model  Specifications 

a.  CHANGE  #14 

b.  Change  Design 

Implementation  of  procedures  for  modifying  the 
contents  of  data  base  records. 

c.  File  Affected 

UP  BOD.  PAS 
MESSAGES. DAT 

d.  Module  Affected 


UPDATE 


e.  Procedure  Changed 
OPDATE_HENO 

f.  New  Procedures 

CHANGE_JOB_TYPE_REC 
CBG__ROOTING_REC 
CBGJSER?EB_REC 
PBINT_REC 

g.  Explanation 

The  new  procedures  implemented  for  changing  of 
data  base  records  are  called  by  the  procedure  OPDATE_NEND  if 
the  respective  option  is  selected  by  the  user.  They  control 
the  seguence  of  events  required  to  compute  the  correct 
record  key,  locate  the  record,  obtain  new  data  and  perform 
changes  in  the  data  records.  All  of  the  procedures  call  the 
new  procedure  PRI NT_EEC  to  display  the  contents  of  the 
records  before  and  after  changes. 

13.  Handling  of  Alphabetic  Characters 

a.  CHANGE  *15 

b.  Change  Design 

The  program  accepts  alphabetic  characters  as 
input  fcr  options  tc  displayed  menus.  The  characters  are 
converted  to  integers  before  selection  of  code  to  be 
executed. 

c.  Files  Affected 


OPHOD.PAS 

CIET.PAS 


d.  nodules  Affected 


HECATE 

SAIN  DRIVES 

e.  Nev  Function 

OP1ION 

f.  Explanation 

In  the  CPMT  program  design,  a  set  of  case 
structures  had  been  implemented  to  process  the  selection  of 
menu  options;  all  the  selection  variables  for  these  control 
structures  are  integers.  In  the  original  version  the  input 
value  which  represents  the  option  is  an  integer  and  is 
assigned  directly  to  the  selection  variable;  in  the  new 
version  the  input  value  is  read  as  a  character  and  converted 
to  integer  by  the  function  OPTION,  and  then  is  assigned  to 
the  selection  variable. 

14.  Printing  of  Eistributions  and  Qeueing  Disciplines 
a.  CHANGE  #16 
t.  Change  Design 

In  order  to  provide  a  more  comprehensafcle 
output,  the  program  distribution  type  and  gueueing 
discipline  codes  are  translated  to  english  before  printing 
on  screen  and  output  file. 

c.  File  Affected 

UPHOD. PAS 

d.  Nodule  Affected 


UPDATE 


e.  Procedure  Changed 

PEINT_B 

£.  New  Procedure 

CCSVEBT_OPT_STR 

g.  Explanation 

Before  printing  either  on  screen  or  output  file 
the  job  type  and  routing  records,  and  for  the  data  items 
distribution  type  and  queueing  discipline,  the  respective 
printing  procedures  call  the  new  procedure  CON VERT_OPT_STR 
to  convert  integer  values  to  preassigned  string  values. 

C.  CONNECTIVE  CHUG  IS 

1.  Error  in  Deleting  a  Simulation  Model 

a.  CHANGE  #17 

b.  Pile  Affected 

UPflOD. PAS 

c.  Nodule  Affected 

UPDATE 

d.  Procedure  Changed 

D  EIE  TE_SI  M_  HOD 

e.  Explanation 

The  original  program  terminates  if  the  last 
simulation  model  in  the  data  base  is  deleted.  The  error  was 
located  in  the  procedure  CHECK_SIM_SPECS,  and  it  was  fixed 
by  adding  the  end  of  file  <EOF)  function,  as  a  condition  to 
be  checked  in  the  while  loop  implemented  to  delete  records. 


2.  Error  as  Exe eating  a  Simulation 


a.  CHANGE  *18 

b.  File  Affected 

CEECKSS.  PAS 

c.  Module  Affected 

CEICK  SIM  SPECS 

d.  Procedure  Changed 

CEEC H_SIH_SPECS 

e.  Explanation 

The  original  program  terminates  if  it  attempts 
to  run  a  simulation  acdel  with  no  records  stored  in  the  data 
Lase.  The  run  time  error  was  fixed  by  calling  the  procedure 
that  checks  errors  in  the  routing  record  specifications  only 
if  no  other  errors  were  found  in  the  head  or  job  type 
records  specification. 

3.  Incorrect  Handling  of  Multj servers 

a.  CHANGE  *19 

t.  File  Affected 

EIT. PAS 

c.  Module  Affected 

EXECUTE  AND  TABULATE 

d.  Procedure  Changed 

FIND  NEXT  EVENT  TIME 


54 


e.  Explanation 

The  algoritha  to  find  the  next  event  foe  a 
servergroup  did  not  work  properly  if  there  is  sore  than  one 
server  specified  for  that  servergroup;  the  results  are 
incorrect  statistics  for  all  jobs  and  individual  job  type. 
The  error  was  located  in  the  procedure  FIND_NEXT_ EVENT_TIME, 
and  it  was  fixed  by  adding  a  test  condition  to  be  checked  in 
the  loop  that  searches  for  the  next  server  to  be  processed. 

0.  TYPE  AID  VOL OH E  Of  CHANGES 

The  relationship  between  the  type  of  change  performed  in 
the  CPMT  prograa  and  its  iapact  in  terns  of  addition  and 
updating  of  procedures  is  illustrated  in  Table  I 


TABU  I 

Type  aad 

Effect  of  Changes 

TYPE 

IMPACT 

ON  THE  PROGRAM 

!  PROCEDURES 

OF 

NEN 

MAJOR 

MINOR 

TOTAL 

<*) 

CHANGE 

CHANGE 

CHANGE 

AIAP1IVE 

13 

10 

6 

29 

(64) 

PERFECTIVE 

4 

7 

2 

13 

(29) 

CORRECTIVE 

- 

- 

3 

3 

(7) 

TOTAL 

17 

17 

11 

Host  of  the  prograa  modifications  were  accoaplished  for 
development  of  the  simulator  modeling  capability  and  prograa 
user  friendliness.  The  effect  of  the  work  performed  to 
correct  errors  in  the  original  program  is  not  significant 
compared  to  the  activity  devoted  to  the  satisfaction  of  new 
requirements. 

E.  I BP ACT  OB  THE  CPBT  USER'S  HA NO A L 

In  order  to  reflect  the  enhancement  of  the  CPMT 
simulator  as  a  result  of  the  changes  described  in  this 
chapter,  rewriting  of  the  CPMT  user's  manual  was  required. 
The  next  chapter  presents  the  new  version  of  the  CPHT  user's 
manual  which  replaces  the  original  described  in  Ref. 2. 


This  chapter  is  intended  for  CPHT  prograa  end  users,  and 
includes  all  the  documentation  needed  to  employ  the 
siaulator  properly.  This  nev  version  of  the  user's  manual 
reflects  the  changes  aade  through  the  aaintenance  effort 
described  in  chapters  2  and  3,  and  provides  the  information 
users  need  to  prepare  a  si aula ti on  aodel  and  run  the 
program. 

A.  GZ1EBAL  DESCHIPTIG*  OF  THE  CPHT 

CEMT  is  a  network-of-gueues  simulator  designed  for 
siaulaticn  of  computer  systems.  The  prograa  creates  and 
maintains  a  database  which  can  store  specifications  for  99 
distinct  models.  Computer  systems  are  modeled  as  collections 
of  server  groups  which  represent  system  components  such  as 
CPU  and  I/O  devices. 

After  modeling  the  computer  system  and  entering  the 
aodel  parameters  in  the  data  base,  users  can  check  for 
correctness  of  the  acdel  specification  before  running  the 
siaulaticn  aodel.  The  program  includes  a  built-in  debugging 
aid  for  simulation  design  which  produces  appropriate  error 
messages  if  the  acdel  specification  does  not  meet  the 
established  reguirements. 

Correct  simulation  models  will  run  for  a  period  of  time 
determined  by  the  user.  Upon  completion  of  the  simulation 
run,  the  prograa  outputs  a  number  of  statistics  related  to 
the  behavior  of  the  simulated  system.  Users  may  then  study 
the  output  and  decide  whether  to  rerun  the  simulation,  to 
change  the  aodel  parameters  or  to  terminate  the  program. 


A  detailed  description  of  the  program  input  ,  output  and 
possible  error  conditions  is  presented  in  the  next  sections. 


B.  BO ESI  DESIG1  AID  SPECIF IC1TI0H 

The  specification  of  a  simulation  model  to  be  run  by  the 
CPST  simulator  involves  characterizing  the  computer  system 
configuration  and  the  workload  handled  by  the  system. 

The  system  configuration  is  characterized  as  a  network 
of  hardware  resources (CPU, I/O  devices  or  terminals)  and 
softwaze  resources  (level  of  programming  and  scheduling 
algorithms) .  The  workload  which  is  processed  by  the  system 
is  represented  in  terms  of  standard  job  types, 
priorities, arrival  rates  and  demands  placed  on  the  various 
resources. 

All  data  parameters  to  describe  the  model,  except  the 
level  of  programming,  are  grouped  into  three  record  types 
for  data  input  and  data  base  storage.  The  level  of 
programming  (number  of  circulating  jobs  in  a  closed  network) 
is  not  stored  in  the  data  base  and  its  specification  is 
entered  interactively  as  the  simulation  model  is  run. 

Each  model  is  assigned  a  simulation  model  number  between 
1  and  99.  The  range  1  to  49  is  to  be  used  for  open  network 
models  and  the  range  50  to  99  for  closed  network  models.  The 
simulation  number  is  used  to  identify  a  particular 
simulation  model  in  the  program  data  base  and  is  ccmmcn  to 
all  the  record  types  developed  to  describe  a  given  model. 

The  servergroup  record  describes  the  nodes  of  the 
computer  system  being  modeled  and  the  job  type  and  routing 
records  describe  the  work  to  be  processed  by  the  system. 

The  rest  of  this  section  presents  a  detailed  explanation 
cf  model  design  and  data  input  format  for  simulation  of 
models  by  the  CPHT.  An  example  of  the  model  design  prccess 
for  a  simple  computer  system  is  provided  for  better 
understanding. 


As  the  internal  clock  of  the  CPHT  is  an  integer, 
arrival  rates  and  service  rates  atist  be  represented  by 
integer  values.  The  designer  of  the  sisulation  aodel  must 
use  (scale  up)  these  tine  units  in  a  consistent  way 
throughout  the  aodel  design  for  correct  output  statistic 
results. 

2.  Server group  Record 

Each  hardware  resource  (or  node)  of  the  computer 
systea(or  network)  is  described  by  a  servergroup  record. 
Each  servergroup  is  comprised  of  one  or  aore  servers  and  is 
serviced  by  a  single  gueue. 2 

The  aaziaua  gueue  length  for  the  servergroup  is 
assumed  to  be  infinite.  The  assignaent  of  a  job  to  a  server 
within  a  servergroup  is  autoaatically  processed  by  the 
program  using  the  following  algoritha:  servers  are  assigned 
to  sequential  numbers  starting  by  one;  a  job  is  assigned  to 
the  idle  server  with  the  lowest  server  number. 

The  servergroup  paraaeters  are  described  below: 
SERVERGROUP  RUBBER  —  the  simulator  has  the  capability  to 
aodel  up  to  9  distinct  servergroups.  The  user  aust  assign 
one  of  the  available  server  group  numbers  (range  1  to  9)  . 

NUHEEE  OF  SERVERS  —  the  simulator  has  the  capability  to 
aodel  a  aaziaua  of  99  servers  within  a  servergroup.  The 
user  specifies  the  number  of  servers  for  each 
servergroup (range  0  to  99);  for  each  servergroup  nuaber 
not  used  in  the  aodel  the  user  aust  specify  "0n  as  the 
nuaber  of  servers  for  that  servergroup. 


2 The  order  in  which  the  jobs  are  served  is  stored  in  the 
routing  record 


3.  29k  H££  £SSSl£ 


Modeling  of  the  system  workload  is  done  by  first 
partitioning  the  jobs  into  classes  according  to  their 
processing  characteristics.  Each  class  is  described  by  a  job 
type  record  and  multiple  routing  records  which  are  linked  to 
that  job  type  record.  The  job  type  data  paraaeters  include 
job  type  number,  job  type  priority,  arrival  rate  and 
distribution  type  and  are  described  below. 

JOB  TYPE  NUMBER  —  each  job  type  is  assigned  a  number 
from  1  to  99  for  purposes  of  identification.  The  program 
assigns  sequential  job  type  numbers  as  the  job  type 
record  data  are  entered. 

JOB  TYPE  PRIORITY  —  for  each  job  type  the  user  specifies 
the  priority  which  that  job  will  have  in  the  system.  The 
priority  range  is  from  1  to  10  with  1  being  the  highest. 
Specification  of  different  job  type  priorities  is 
insignificant  if  the  jobs  are  to  be  served  at  the 
servergroups  with  a  nonpriority  dependent  gueueing 
discipline. 

AERIVA1  DISTRIBUTION  TYPE  AND  DISTRIBUTION  PARAMETER  — 
in  order  to  describe  the  job  type  arrival  rate  into  the 
system,  the  user  selects  the  distribution  type  and 
distribution  parameter.  These  parameters  are  not  entered 
for  closed  network  models  {because  in  a  closed  network 
there  are  no  departures  or  arrivals,  and  in  order  to 
model  this,  CPMT  automatically  schedules  one  arrival  at 
exactly  the  time  cf  every  departure)  .  The  distribution 
type  and  distribution  parameter  options  are  discussed  in 
more  detail  later  in  this  chapter. 


4 .  Sou ting  Becord 


Each  routing  record  represents  one  step  in  the 
routing  of  a  job  type  and  has  two  functions,  to  describe  the 
service  to  be  processed  at  each  servergroup  and  to  provide 
the  branching  probabilities  froa  that  servergroup  to  all  the 
ether  servergroups  in  the  systen. 

In  order  to  aodel  the  entrance  and  exit  of  jobs  into 
the  systea,  two  dunmy  servergroups,  3  and  1 0,  aust  be 
descibed  as  part  of  aodel  design.  However,  no  service  is 
perforaed  in  these  servergroups  and  so  there  is  no 
specification  of  server  records  for  these  servergroups.  The 
entrance  and  exit  servergroups  aust,  however,  be  included  in 
the  branching  probabilities.  The  routing  record  parameters 
are  : 

SERVICE  DISTRIBUTION  TYPE  and  DISTRIBUTION  PARAMETER  — 
the  service  deaand  for  the  job  type  is  defined  by  a 
distribution  type  and  a  corresponding  parameter.  The 
detailed  discussion  of  these  parameters  is  provided  later 
in  this  chapter  under  a  separate  header. 

QUEUEING  DISC IP LI  BE3  —  the  gueueing  discipline  in  which 
the  jot  type  is  served  is  identified  by  an  integer  value 
btueen  1  and  7.  The  gueueing  disciplines  currently 
implemented  in  the  CPHT  and  the  corresponding 
identification  code  are  listed  in  Figure  4.1. 

ROUTING  PR OB ABILITIES  —  the  routing  probability  is 
implemented  as  a  one  dimensional  array  of  integers.  The 
entries  in  this  array  represent  the  probability  that  the 
particular  job  type  will  go  from  the  current  server  group 
to  each  of  the  other  server  groups  in  the  model.  The 
routing  probability  is  an  integer  from  0  to  100.  The 


3the  gueueing  discipline  is  stored  in  the  routing  record 
rather  than  in  the  servergroup  record  for  CPNT  design 
convenience. 


CODE 


QUEUEING  DISCIPLINE 


ABREV. 


1 

First  Cone  First  Served 

(FCFS) 

2 

Last  Cone  First  Served 

(LCFS) 

3 

Nonpreemptive  Priority 

(HP) 

4 

Shortest  Proc.  Time  First 

(SP1F) 

5 

Lowest  Weighted  Proc. Time  First 

(LMPTF) 

6 

Processor  Sharing 

(PS) 

7 

Served  in  Randcm  Order 

(SIRO) 

Figure  4.1  Queueing  Disciplines 

routing  record  design  must  meet  established  reguirements 
which  are  discussed  further  in  the  "routing  design 
rules". 

5 .  Distribution  Specification 


To  describe  the  arrival  rate  of  job  types  or  their 
service  rates  at  the  servergroups,  the  user  selects  one  of 
three  available  distribution  types,  DETERMINISTIC, 
EXPONENTIAL  or  UNIFORM,  and  also  provides  a  parameter  (range 
1  to  99999)  to  specify  the  value  (s)  of  the  rate.  The 
distribution  types  and  corresponding  distribution  parameters 
are  listed  in  figure  4.2. 

s.  laaiiaa  Vasias  sales 

The  routing  design  for  each  job  type  must  satisfy 
the  following  rules: 

-  a  routing  record  is  required  for  the  entrance 
servergroup  (SG  0).  Since  no  processing  is  done  at  this 


CODE 


DISTRIBUTION 


PARAMETER 


1  DETERMINISTIC  DETERMINATE  VALUE 

2  EXPONENTIAL  MEAN  VALUE 

3  UNIFORM  UPPER  BOUND 


J 


Figure  4.2  Distribution  Types  and  Parameters 

server,  no  values  are  assigned  to  the  service 
distribution  type  or  distribution  paraseter,  but  routing 
probabilities  frca  this  servergroup  to  the  working 
servergroups (SG  1  through  9)  Bust  be  provided. 

-  jobs  nust  be  routed  to  the  exit  servergroup  (SG  10) 
fron  at  least  one  working  servergroup;  no  routing  record 
is  reguired  for  the  exit  servergroup  because  no 
processing  is  done  at  this  servergroup  and  because  a  job 
is  not  routed  to  any  other  servergroup. 

the  sub  of  the  routing  probabilit ies  fron  a  given 
servergroup  to  all  others  must  be  egual  to  100. 

-  the  probability  of  routing  a  job  from  a  given 
servergroup  to  itself  Bust  not  be  egual  to  100  to  avoid 
generating  a  job  which  never  cooplete  processing. 

if  a  job  type  is  routed  to  a  servergroup,  then  a 
routing  record  nust  exist  for  that  job  type  from  that 
servergroup. 


7.  I&gul  Format 


In  order  to  facilitate  the  online  input  of  the  model 


data  specification  and  provide  documentation  of  the  nodel, 
the  user  should  fill  out  one  servergroup  record  data  fors 
shown  in  Fig  4.3  per  siaulation  model,  and  one  job  type  and 
routing  record  data  fors.  Fig  4.4  ,  for  each  job  type  in  the 
aodel. 


Siaulation  nun her  : 

Server  Group  Munber  :  Number  of  Servers  : 

1 
2 

3 

4 

5 

6 

7 

8 
9 


Figure  4.3  Servergroup  Record  Data  Fora 

8.  IiaiBlS  o£  &s£el  Design 

An  illustration  of  the  model  design  process  is 
presented  below,  using  a  computer  system  described  by  SAUER 
£Re£.  1  :p.376].  Part  of  the  aodel  specifications  will  also 
be  used  as  an  exaxple  for  the  user  program  dialogue 
described  in  the  next  section  "HOW  TO  RUN  THE  SIMULATOR". 


Simulation  Humber  :  Job  Type  Humber  : 

***************  jpg  TYPE  BECOBD  ***************** 

Arrival  Dist  : 

Oist  Param  : 

Priority  : 

***************  BOOTING  BECOBD  ***************** 
Servergroup  :  0123456789 

Service  Dist: 

Dist  Param  : 

Queue  Disc  : 

Bouting  To  : 

SG  1 
SG  2 
SG  3 
SG  4 
SG  5 
SG  6 
SG  7 
SG  8 
SG  9 
SG  10 


Figure  4.4  Job  Type  and  Bouting  Becord  Data  Fora 


This  model  was  also  simulated  for  validation  of  CPHT  and  the 
results  are  discussed  in  Chapter  5. 

a.  The  System 


The  computer  which  is  to  be  modeled  is  a 
multi  programmed  system  having  four  memory  partitions.  The 
system  has  a  single  processor  and  two  I/O  devices,  a  floppy 


disk  and  a  hard  disk,  sharing  a  common  channel.  The  hardware 


organization  is  illustrated  in  Figure  4.5. 


Figure  4.5  Coaputer  System  H/B  Organization 


The  CPU  scheduling  algorithm  is  a  low  overhead 
Bound  Robin  which  can  be  considered  to  be  equivalent  to 
Processor  Sharing  (PS)  and  the  I/O  reguests  are  served  in  a 
First  Come  First  Served  basis.  The  system  is  to  be  simulated 
with  all  memory  partitions  in  use.  The  degree  of 
multiprogramming  ,  average  service  times  and  branching 
probabilities  derived  from  the  system  accounting  data 
recorded  during  a  period  of  heavy  workload  are  illustrated 
in  Figure  4.6. 

t.  The  Model 

Assuming  that  there  is  a  sufficient  bacjclcg  of 
jobs  and  there  is  a  sufficient  memory  contention  that  the 
degree  cf  multiprogramming  is  essentially  constant,  the 
system  can  be  modeled  by  a  closed  queueing  central  server 
network  model.  The  central  processor  is  represented  by 
servergroup  1  preceeded  by  a  queue,  and  the  disks  are 
represented  as  servergroups  2  and  3,  each  one  with  a 


DEGHEE  OF  MULTIPROGRAMMING  .  4 

AVERAGE  CPU  SERVICE  TIME  . .  0.05  sec 

AVERAGE  FLOPPY  DISK  SERVICE  TIME  ....  0.220  sec 

AVERAGE  HARD  DISK  SERVICETIME  .  0.019  sec 

PROBABILITY  OF  JOB  COMPLETION 

AFTER  DISK  SERVICE .  0.125 

PROBABILITY  OF  FLOPPY  ACCESS  .  0.1 


I 


Figure  4.6  Data  Parameters 

respective  queue.  Servergroups  2  and  3  are  organized  in 
parallel  with  respect  to  the  central  processor.  Two 
additional  dummy  servers,  entrance  (SG  0)  and  exit  (SG  10) 
are  included  as  required  by  the  CPMT.  The  model  is 
illustrated  in  Fig  4.7. 

Service  times  are  assumed  to  be  exponentially 

distributed. 

c.  Input  Model  Parameters 

As  the  system  is  represented  by  a  closed 
network,  a  simulation  number  in  the  range  50  to  99  must  be 
assigned  to  the  sixulation  model.  For  this  example  the 
simulaticn  number  60  was  arbitrary  chosen. 

SERVERGROOP  RECORE  —  the  model  has  three  servergroups 
SGI  (CPU),  SG2  (FICPPY  DISK)  and  SG3  (HARD  DISK)  each  one 
consisting  of  a  single  server.  The  servergroup  record 
data  fora  for  this  model  is  displayed  in  figure  4.8. 


Simulation  number  ;  60 

Server  Group  Number  : 

Number  of  Servers  : 

1 

1 

2 

1 

3 

1 

4 

0 

5 

0 

6 

0 

7 

0 

8 

0 

9 

0 

JOB  TIPE  BE CO BO  —  the  computer  system  has  only  one  job 
type  which  will  be  designated  as  job  type  1,  and  since 
there  is  only  one,  the  priority  is  insignificant.  Is  the 
model  is  a  closed  network,  arrival  distribution  type  and 
distribution  parameter  are  not  considered. 

BOOTIHG  BECOBDS  —  three  routing  records  are  required  to 
describe  the  service  processed  at  the  servergroups  and 
routing  of  jobs  through  the  system.  As  stated  in  the 
routing  design  rules  an  additional  servergroup  (entrance 
servergroup)  record  is  required  for  job  routing  purpose. 

The  smallest  amount  of  time  represented  in  the 
model,  as  listed  in  Fig  4.6  is  the  hard  disk  service,  which 
is  0.019.  Therefore,  all  the  time  values  are  multiplied  by 
1000  so  that  they  are  all  integers  (time  unit  = 
millisecond)  •  The  mean  service  times  are  then  : 


SG 

1  .... 

...  50 

SG 

2  .... 

...  220 

SG 

3  m  m  m  • 

...  19 

The  routing  probabilities  to  be  assigned  are 
derived  from  data  shown  in  Fig  4.6  ,  applying  the  routing 
design  rules  for  CPST.  As  the  processing  of  jobs  is 
initiated  by  CPO  service,  the  routing  probability  from  the 
entrance  servergroup  SG0  to  SGI  is  100.  The  routing 
probability  from  SGI  to  SG2  is  10  and  from  SGI  to  SG3  is  90 
(100  -  10).  As  the  probability  of  job  completion  after  disk 
service  is  0.125,  the  rounded  value  in  the  range  0  to  99  is 
13.  Thus  the  routing  probabilities  from  SG2  and  SG3  to  the 
exit  servergroup  SG10  are  13.  The  remaining  routing 
probability  (for  new  CPO  service)  is  87,  thus  the  routing 
probabilities  from  SG2  and  S3  to  SGI  are  87.  The  job  type 
and  routing  records  data  form  for  the  model  are  illustrated 
in  Fig  4.9. 


Simulation  Number  :  60 


Job  Type  Number  :  1 
♦♦♦*♦♦**♦******  JOB  TYPE  BECOBD  ***************** 
Arrival  Dist  : 

Dist  Param  : 

Priority  :  1 


*************** 

BOUTING 

Server group 

:  0 

1 

2 

Service  Dist 

: 

2 

2 

Dist  Param 

: 

50 

220 

Queue  Disc 

: 

6 

1 

Bouting  To 

SG  1 

100 

0 

87 

SG  2 

0 

10 

0 

SG  3 

0 

90 

0 

SG  4 

0 

0 

0 

SG  5 

0 

0 

0 

SG  6 

0 

0 

0 

SG  7 

0 

0 

0 

SG  8 

0 

0 

0 

SG  9 

0 

0 

0 

SG  10 

0 

0 

13 

BECOBD  ***************** 

3  4  5  6  7  8  9 

2 

19 

1 

87 

0 

0 

0 

0 

0 

0 

0 

0 

13 


Figure  *.9  Model  Job  Type  and  Boating  Fora 
C.  HON  TO  BIJ1  THE  SIBUL1TOB 

CPHT  runs  on  the  VAX/VHS  Computer  Science  Department 
Computer  at  NPS.  To  execute  the  program  after  logging  onto 
the  computer,  enter  the  command  RON  CPHT  in  response  to  the 
$  prompt. 


The  prograa  initially  displays  to  the  user  the  MASTER 
HERO  of  prograa  options  presented  in  Fig.  4.10  The  user 
enters  the  integer  value  corresponding  to  the  option 
desired.  Ihenever  an  invalid  option  is  entered  the  menu  is 
redisplayed.  A  description  of  each  option  follov  under 
separate  headings. 


-  ENTER  NEB  SIMULATION  NUMBER 

-  UPDATE  SIMULATION  SPECIFICATIONS 

-  CHECK  SIMULATION  SPECIFICATIONS 

-  BON  SI  MU  I  AT  ION  MODEL 

-  PRINT  ALL  DATA  BASE 

-  PRINT  DATA  BASE  FOB  A  SINGLE  MODEL 

-  DELETE  SIEULATION  MODEL 

-  COPY  SI  MUTATION  MODEL 

-  DISPLAY  SIMULATION  MODEL  SPECIFICATIONS 

-  EXIT  CPMT  ENVIRONMENT 


Figure  4.10  Master  Menu  Options 


At  several  points  in  the  program,  the  user  directs 
prograa  control  by  responding  to  questions  which  have  "yes'1 
or  "no”  answers.  The  convention  for  the  CPMT  program  is  that 
the  user  enters  either  the  uppercase  or  lowercase  wy"  for  a 
wyes"  response  and  any  other  character  for  a  negative 
response. 

Each  simulation  acdel  is  identified  by  a  unique  integer 
value  called  the  simulation  number.  The  user  may  assign  a 
simulaticn  model  an  integer  number  in  the  range  1  to  49  for 
CPEN  NETHORK  MODELS  and  50  to  99  for  CLOSED  NETNORK  MODELS. 


1.  Enter  a  Sew  Simulation  Sunber 


This  function  is  to  be  selected  if  the  user  wishes 
to  add  a  new  simulation  model  to  the  simulator  data  base. 

Opon  entry  of  the  integer  value  "I"  corresponding  to 
this  option  the  program  displays  either  the  simulation 
numbers  already  existing  in  the  data  base,  or  the  message  : 

HO  SIMULATION  NUMEIBS  IN  DATA  BASE 

and  prompts  for  entering  of  the  simulation  number.  At  this 
point  the  user  enters  the  desired  simulation  number  for  the 
new  model.  If  a  simulation  number  out  of  the  1  to  99  range 
is  entered,  the  message 

EBROB  IN  INPOT 

is  displayed  and  the  simulation  number  is  prompted  again. 
Otherwise,  if  the  user  enters  a  simulation  number  already 
existing  in  the  data  base,  the  message 

SIMULATION  MODEL  NUMBER  ALREADY  EXISTS  IN  DATA  BASE 


is  displayed  and  the  program  will  return  to  the  Master  Menu 
on  the  entry  of  any  character.  Otherwise  the  update  options 
are  presented  to  the  user  in  a  menu  format,  OPBATE  MEND, 
similar  to  that  of  the  MASTER  MENU.  The  update  menu  options 
are  listed  in  Fig  4.11  and  are  explained  further  in  this 
section  under  a  separate  header. 


Qpdate  Model 


This  function  is  to  be  selected  if  the  user  wishes 
to  update  the  specifications  cf  a  simulation  model  already 
existicg  in  the  simulator  data  base.  This  function  is  also 
automatically  selected  after  a  new  simulation  number  has 
been  selected. 


1  -  ADD  JOB  TYPE  RECOB D 

2  -  ADD  ROOTING  RECORD 

3  -  ADD  SERVERGROUP  RECORD 

4  -  DELETE  JCB  TYPE  RECORD 

5  -  DELETE  ROUTING  RECORD 

6  -  DELETE  SERVERGROOP  RECORD 
1  -  CHANGE  JCB  TYPE  RECORD 

8  -  CHANGE  ROUTING  RECORD 

9  -  CHANGE  SERVERGROOP  RECORD 
0  -  RETURN  TO  HASTES  MENU 


Figure  4.11  Update  Menu  Options 

Upon  entry  of  the  integer  value  2  corresponding  to 
this  option,  the  program  proapts  the  user  to  input  the 
siaulaticn  nuaber.  If  the  user  eaters  a  simulation  number 
that  does  not  exist  in  the  data  base  the  following  aessage 
is  displayed  : 

SIMULATION  MODEL  COES  NOT  EXIST  IN  DATA  BASE 

In  this  case  progra*  control  returns  to  the  Master  Menu 
after  entry  of  any  character,  otherwise  the  update  options 
are  presented  by  the  UPDATE  MENU. 

3.  Check  Simulation  Specifications 

This  option  is  used  as  a  debugging  aid  to  check  if  a 
given  simulation  model  meets  the  specification  requirements 
for  a  successful  simulation  run. 

The  program  will  prompt  the  user  to  input  the  number 
of  the  simulation  model  to  be  checked.  As  the  user  enters 
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the  simulation  model  number,  the  existence  of  data  records 
and  observation  of  the  routing  rules  are  tested  for  the 
specified  model.  If  the  simulation  model  does  not  meet  the 
reguirements  the  following  message  is  displayed  : 

SINULATION  SPECIFICATIONS  DID  NOT  CHECK 
EBBOB  HESSAGES  IN  FILE  OOTFILE.DAT 

The  error  messages  will  help  the  user  to  eliminate  the  model 
specification  deficiencies.  The  list  of  possible  error 
messages  is  presented  in  Figure  4.12. 


1.  Simulation  Number  Does  Not  Exist. 

2.  No  Server  Group  Becord  Exists. 

3.  No  Job  Type  Exists. 

4.  Jcb  Numbers  Axe  Not  Sequential. 

5.  Server  Group _ #  Job  Type _  Routing  Loop. 

€•  No  Routing  Records  Exist  for  Job  Type _ . 

7.  No  Server  Group  0  Routing  Record  For  Job  Type _ . 

8.  Job  Type not  Routed  to  Exit  Server  Group. 

9.  Job  TTpe Routed  To  But  Not  From  Server  Group . 


Figure  4.12  Simulation  Specification  Error  Jlessages 

If  the  simulation  model  is  correctly  specified  the  following 
message  is  displayed  ; 

S ISOLATION  SPECIFICATIONS  CHECK 


In  both  cases  the  program  control  returns  to  the  {faster  Menu 
by  entry  cf  any  character. 


4.  isi  a  slaaiatiofi. 


This  option  is  selected  if  the  user  wishes  to 
execute  the  si  aula  tics  of  a  so  del. 

The  prograa  will  first  proapt  the  user  to  input  the 
nuaber  of  the  aodel  to  be  run  and  then  displays  a  aenu  with 
the  options  for  specification  of  run  duration,  nuaber  of 
jobs,  clock  tiae  or  nuaber  of  events  (  or  the  last  two 
options  for  closed  network  models) .  Upon  entering  the  option 
the  prograa  displays  the  prompt  for  entering  of  the 
corresponding  parameter,  is  the  user  enters  the  nuaber  of 
jobs,  simulation  tiae  or  number  of  events  to  be  processed, 
depending  on  the  specification  type  selected,  the  prcgraa 
prompts  for  a  seed  value.  The  seed  will  be  used  as  initial 
input  into  the  system  random  number  generator.  The  random 
numbers  in  turn  are  used  as  input  into  program  functions 
which  require  random  variables. 

At  this  point  the  prograa  asks  if  the  user  wishes 
the  prograa  to  specify  the  interval  of  tiae  for  statistics 
(the  program  can  produce  statistics  about  the  behavior  of 
the  siaulated  system  for  a  period  of  time  during  siaulation 
or  for  all  siaulaticn  tiae) .  If  the  user  response  is 
affiraative,  the  start  tiae  and  stop  time  for  gathering 
statistics  will  be  reguested. 

If  the  siaulation  aodel  to  be  run  is  a  closed 
network,  the  prograa  will  ask  the  user  to  input  an 
additional  aodel  specification,  the  degree  of  programming. 
The  degree  (or  level)  of  prograaaing  represents  the  nuaber 
of  jots  to  be  processed  in  the  closed  network  and  is 
prompted  for  each  job  type  in  the  model.  A  complete  example 
of  the  user  prograa  dialogue  for  execution  of  a  closed 
network  siaulation  model  is  illustrated  in  Fig.  4.13. 

Before  executing  the  siaulation  aodel  the  prograa 
will  check  the  siaulation  specifications.  If  the  aodel  is 


not  correctly  specified  the  following  aessage  will  be 
displayed  : 

S ISOLATION  HODEL  NOT  EXECOTEO 

SI BULATION  MODEL  SPECIFICATIONS  DO  NOT  CHECK 

ERROR  MESSAGES  IN  FILE  OOTFILE.DAT 


ENTEfi  SIMULATION  NUMBER  OF  HODEL  TO  EXECUTE 
65 

ENTER  SPECIFICATION  TYPE  FOB  BON  DOBATION 

1-  CLOCK  TIME 

2-  NUMBER  OF  EVENTS 

1 

ENTER  SIMULATION  REN  DURATION 
150000 

ENTER  THE  SEED  TOO  RANT  TO  USE 
45367 

DO  YOU  RISH  TO  SPECIFY  THE  INTERVAL  TIME  FOR  GATHERING 
STATISTICS  ?  y/- 

Y 

ENTER  START  TIME  ICR  STATISTICS 
300 

ENTER  STOP  TIME  FCS  STATISTICS 
120000 

ENTER  DEGREE  OF  PROGRAMMING  OF  JOB  TYPE  1 
4 


Figure  4.13  Example  of  Execute  Siaulation  Model  Dialogue 


The  possible  error  aessages  are  those  already  referenced  and 
illustrated  in  Figure  4.12.  Otherwise  if  the  simulation  run 
duration  is  selected  by  clock  time  and  no  jobs  coaplete 


within  the  simulation  period,  the  following  error  message 
will  he  displayed  : 

EBBOfi  -  SIMULATION  MODEL  EXECUTED  BUT 
NO  JOBS  COMPLETED  DOBING  SIMULATION  TIME 

In  both  cases  the  prograa  returns  to  Master  Menu  by  entry  of 
any  character. 

If  the  execution  is  successful  the  statistical 
output  will  be  written  in  the  file  OUTFILE.DAT  and  the 
following  message  will  be  displayed  : 

SIMULATION  MODEL  E1ECUTED 

OUTPUT  STATISTICS  IN  FILE  OUTFILE.DAT 

DO  YOU  NISH  TO  BUN  THE  SIMUIATION  AGAIN  ?  y/- 

If  an  affirmative  response  is  entered  the  prograa  dialogue 
will  be  repeated  for  rerunning  the  same  simulation  model, 
otherwise  the  user  is  given  the  option  of  exiting  the 
function  or  attempting  to  run  other  simulation  model. 

The  output  statistics  include  minimum,  maximum,  mean 
and  standard  deviation  of  time  in  system  and  time  in  queue, 
throughput  and  mean  number  of  jobs  in  the  system  for  all 
jobs  and  for  each  job  type,  and  maximum,  minimum  and  mean 
gueue  size  and  utilization  by  server  group  and  server  within 
a  server  group.  An  example  of  the  output  report  format  is 
illustrated  in  Figure  4.14. 
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5.  Hint  faia  lass 


This  option  is  used  for  monitoring  of  the  CPHT  data 
tase  workload. 

Opon  selection  of  this  option,  a  printout  of  the 
entire  indexed  seguential  data  base  is  written  to  the  file 
0UTFI1E.DAT.  The  program  control  returns  to  Master  Menu  by 
entering  of  an  arbitrary  character.  If  the  user  wishes  a 
hard  copy  a  print  out  aust  be  requested  fro m  outside  the 
CPHT  environment. 

6.  fjint  Data  Base  foy  a  Single  Model 

This  function  is  to  be  selected  if  the  user  wishes  a 
printout  of  a  given  simulation  model  specification. 

Opon  selection  of  this  option,  the  prograa  asks  the 
user  to  input  the  simulation  number.  Opon  entry  of  the 
simulation  model  number,  the  prograa  attempts  to  find  the 
simulation  model  in  the  data  base.  If  the  simulation  model 
exists,  the  program  writes  all  the  records  for  that  model  to 
the  file  ODTFILE.DAT,  and  displays  the  message: 

MCDEI  SPECIFICATION  IN  Fill  OOTFILE.DAT 

The  user  then  requests  a  printout  of  the  file  from  outside 
the  CFMT  environment.  If  the  simulation  model  number  is  not 
found  the  message 

SIHOIATION  MODEL  DOES  NOT  EXIST  IN  DATA  BASE 

is  displayed.  In  either  case  the  user  is  given  the  option  of 
exiting  this  function  ,  or  attempting  to  print  another 
simulation  model. 

7.  Delete  3,  Simulation  Model 

This  option  is  used  to  delete  a  complete  simulation 
model  from  the  data  base. 
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Upon  selection  of  this  option  the  prograa  prompts 
for  entry  of  the  simulation  model  number.  After  the  user 
enters  the  simulation  number  the  program  attempts  to  find 
the  model  in  the  data  base.  If  the  number  of  the  model  does 
not  exist  an  error  message  is  displayed,  otherwise  the 
program  gives  the  user  the  option  of  deleting  the  model.  If 
the  user  responds  affirmatively  the  program  deletes  all  of 
the  records  for  the  chosen  simulation  model  from  the  data 
base  and  displays  the  message: 


SIMULATION  MODEL 


DELETED. 


At  the  end  of  the  dialogue  the  user  is  given  the 
option  of  exiting  function  or  attempting  to  delete  other 
simulation  model. 

8.  Copy  a  Simulation  Model 

The  copy  option  is  convenient  if  the  user  wishes  to 
compare  the  simulation  results  of  two  models  with  a  few 
changes  in  parameter  specifications.  In  this  case  the  user 
can  copy  one  model  tc  a  new  number,  maxe  the  changes  in  the 
copy,  and  maintain  both  model  design  specifications  in  the 
data  base. 

Upon  selection  of  this  option  the  program  displays 
the  prompt  for  entering  the  simulation  model  number  which  is 
to  be  copied  and  the  model  number  of  the  copy.  If  the  number 
of  the  model  to  be  copied  does  not  exist  the  following 
message  is  displayed  : 


SIMULATION  MODEL  NUMBER 


DOES  NOT  EXIST  IN  DATA  BASE 


Otherwise,  if  the  new  simulation  model  number  is  already  in 
the  data  base  the  following  message  is  displayed  : 


SIMULATION  MODEL  NUMBER 


ALREADY  EXISTS  IN  DATA  BASE 


If  the  copy  is  successful  the  following  message  is  displayed 
SIMULATION  MODEL  COPIED 


jy 


At  the  end  of  the  dialogue  the  user  is  given  the  option  of 
exiting  the  function  or  attempting  to  copy  another 
simulation  model. 

9.  Display  Simulation  Model  Specifications 

This  option  is  used  for  on-line  review  of  simulation 

models. 

Upon  selection  of  this  option  the  program  prompts 
for  entry  of  the  simulation  model  number  and  then  attempts 
to  find  the  model  in  the  data  base.  If  the  simulation  model 
does  not  exist  an  appropriate  message  will  be  displayed, 
otherwise  the  program  asks  the  user  to  input  the  type  of 
record  to  be  reviewed  (job  type  ^routing  or  servergroup) .  If 
the  user  selects  either  the  job  type  or  the  routing  record, 
the  program  asks  the  user  to  identify  the  job  type  number. 
The  record  data  will  be  directly  displayed  for  the  job  type 
record  and  the  identification  of  the  routing  record  number 
to  be  displayed  will  be  prompted  for  the  routing  record 
option.  If  a  servergroup  record  is  selected  for  user  review 
the  program  asks  the  user  to  identify  the  servergroup  number 
and  then  displays  the  record  data. 

For  all  the  options  the  program  displays  error 
messages  if  the  user  attempts  to  display  data  from 
nonexistent  records. 

After  record  data  review  the  user  is  given  the 
option  of  displaying  another  record  for  the  same  model.  If  a 
negative  response  is  entered,  the  user  is  given  the  option 
of  exiting  the  function,  returning  to  the  Master  Menu 
options  or  displaying  another  model. 

The  user  program  dialogue  for  displaying  a  routing 
record  is  shown  in  Figure  4. 15. 


************************************************ 

DISPLAY  SIMULATION  MODEL  FUNCTION 

************************************************ 

ENTER  SIMULATION  NUMBER  YOU  NISH  TO  DISPLAY  DATA 


ENTER  RECORD  TYPE  YOU  NISH  TO  DISPLAY 


1-  JOB  TYPE 

2-  ROUTING 

3-  SERVERGROUP 


ENTER  JOB  TYPE  NUMEER 


ENTER  ROUTING  RECORD  NUMBER 
3 

(clear  screen) 

(display  of  function  header) 

SERVICE  DISTRIBUTION  IS  :  EXPONENTIAL 
DISTRIBUTION  PARAMETER  IS  :  19 

QUEUEING  DISCIPLINE  IS  :  FCFS 


ROUTING 

ROOTING 

ROUTING 

ROUTING 

ROUTING 

ROUTING 

ROUTING 

ROUTING 

ROUTING 

ROUTING 


PR  OB  TO 
PROB  TO 
PROB  TO 
PROB  TO 
EROB  TO 
PROB  TO 
PROB  TO 
PROB  TO 
PROB  TO 
PROB  TO 


1  IS 

2  IS 

3  IS 

4  IS 

5  IS 

6  IS 

7  IS 

8  IS 

9  IS 
10IS 


DC  YOU  NISH  TO  DISPLAY  MORE  RECORDS  ?  Y/- 


DO  YOU  NISH  TO  EXIT  FUNCTION  ?  Y/- 


Fxgare  4.15  Example  of  Display  Siaulation  Model  Dialogue 


10.  £xii  CPqT  Environment 

Upon  selection  of  this  option  the  program  execution 
terminates  and  control  returns  to  the  system 


11.  Updating  Options 


The  functions  for  data  base  record  updating  that  are 
presented  by  the  UPDATE  MENU  are  related  to  a  siaulation 
model  number  already  entered  by  the  user  after  either 
selecting  the  opticn  "Enter  New  Simulation  Number"  or 
"Update  Model  Specifications"  from  the  MASTER  MENU.  The 
Record  Updating  functions  are  explained  below. 

a.  Add  Job  Type  Record 

Upon  selection  of  this  option  the  program 
automatically  accesses  the  simulation  model  in  the  data  base 
to  determinate  the  next  available  job  type  number  for  the 
given  siaulation  model  and  assigns  that  number  to  the  job 
type  to  be  added.  The  program  then  requests  the  user  to 
input  the  arrival  distribution  and  distribution  parameters,4 
and  priority  of  the  job  type.  Input  data  values  are  echoed 
as  they  are  entered,  to  allow  the  user  to  detect  incorrect 
data.  The  program  alsc  prompts  for  re-input  of  invalid  data. 

As  the  job  type  record  data  is  entered  the 
program  displays  the  entries  for  review  and  asks  if  the  user 
wishes  to  add  the  job  record.  If  the  user  chooses  to  add  a 
job  type  record  which  exists  in  the  data  base,  the  program 
responds  with  the  message 

RECORD  AIR  EADY  EXISTS,  NOT  ADDED 

otherwise  the  job  type  record  is  added  to  the  data  base  and 
the  message 

RECORD  SUCCESSFUL!!  ADDED 


♦These  two  parameters  are  not  requested  for  closed 
network  models 


is  displayed.  If  the  user  chooses  not  to  add  the  record  the 
prograa  displays 

BECCBD  SOT  ADDED 

If  the  job  type  record  is  successful  added  the  option  of 
going  directly  to  the  Add  Bouting  Becord  function  (see  next 
option)  is  provided.  The  prograa  control  will  return  to  the 
add  job  type  function  upon  exit  from  the  add  routing  record 
function. 

The  user  aay  add  aultiple  job  type  records  to  a 
aodel.  At  the  end  of  every  iteration  of  the  option  dialogue 
the  user  is  given  the  choice  of  exiting  the  function  or 
adding  another  job  type  to  the  aodel. The  dialogue  for 
addition  cf  a  job  type  record  is  illustrated  in  Fig  4.16. 

b.  Add  Bouting  Becord 

This  opticn  can  be  entered  either  directly  from 
the  add  job  type  function  as  explained  above,  or  froa  the 
update  menu.  When  the  user  selects  this  option  from  the  add 
job  type  function,  the  routing  records  are  automatically 
added  to  the  job  type  record  just  added.  Otherwise  the 
program  will  ask  the  user  to  identify  the  job  type  number 
for  which  routing  records  are  to  be  added.  If  the  job  type 
number  is  not  found  in  the  data  base  the  following  error 
message  is  displayed: 

EBROB  THE  JOB  TUI  BECOBD  DOES  NOT  EXIST 

If  the  record  job  type  is  found  the  program  reguests  the 
user  to  input  the  routing  parameters  of  servergroup  number, 
service  distribution,  distribution  parame ter,gueueing 
discipline  and  routing  probabilities. 

As  in  the  "add  job  type  function"  the  input  data 
and  the  entire  data  record  are  displayed  for  user  review. 
The  user  is  given  the  option  of  adding  the  routing  record  . 


********************************************** 


ADD  JOB  TYPE  RECORD  FUNCTION 

********************************************** 

SIMULATION  MODEL  NUMBER:  60  * 

JOE  TYPE  NUMBER: 1 

ENTER  PRIORITY  FOR  THIS  JOB  TYPE: 

VALID  PRIORITY  CODES  ARE  1  THRU  10 

1 

(clear  screen) 

(display  of  function  header) 

(display  of  the  job  type  record) 

DC  YOU  WISH  TO  ADD  RECORD  TO  THE  DATA  BASE  ?  Y/- 

Y 

RECORD  SUCCESSFUL  ADDED 

DO  YOU  WISH  TO  ADD  ROUTING  RECORDS  FOR  THIS  JOB  TYPE? 

N 

DO  YOU  WISH  TO  EXIT  FUNCTION  ?  Y/- 

Y 

*  As  the  model  is  a  closed  gueueing  network 

arrival  distribution  type  and  distribution  parameter 
are  not  prompted 


Figure  4. 16  Add  Job  Type  Record  Dialogue 


If  the  user  chooses  to  add  an  existing  routing  record,  the 
record  is  not  added  and  an  error  message  is  displayed. 

At  the  end  of  the  function  dialogue  the  user  has 
the  option  of  exiting  the  function  or  adding  another  routing 
record  to  the  model. 

An  example  of  the  user  program  dialogue  for 
adding  a  routing  record  with  selection  from  the  UPDATE  MENU 
is  displayed  in  Figure  4. 17. 


********************************************** 
ADD  ROOTING  RECORD  FUNCTION 
********************************************** 

SIMULATION  NO DEI  NONBER:  60 

ENTER  JOE  TYPE  NONBER  OF  ROOTING  RECORDS  TO  BE  ADDED 


ENTER  ROOTING  RECORD  SERVER  GROUP  NONBER: 


ENTER  SERVICE  RATE  DISTRIBUTION:  1-DETERNINATE 

2-  EXPONENTIAL 

3- ONIFORH 


ENTER  EXPONENTIAL  DISTRIBUTION  MEAN: 
220 


ENTER  QUEUEING  DISCIPLINE: 

1- FIRST  CONE  FIRST  SERVED 

2- LAST  CONE  FIRST  SERVED 

3- NONPREHPTIVE  PRIORITY 

4- SHORT.  PROC.  TIME  FIRST 

5- LOW.  WEI. PROC. TIME  FIRST 

6- PROCESSOR  SHARING 

7-  SERVICE  IN  RAND.  ORDER 


(FCFS) 

[LCFSj 

NP) 

SPTF) 

LWPTF) 

PSf 

SIRO) 


ENTER  THE  ROUTING  PROBABILITY  FROM  SERVER  GROUP  2  TO 

SERVER  GROUP  Is  87 

SERVER  GROUP  2:  0 

SERVER  GROUP  3:  0 

SERVER  GROUP  4:  0 

SERVER  GROUP  5:  0 

SEBVER  GROUP  6:  0 

SERVER  GROUP  7:  0 

SEBVER  GROUP  8:  0 

SERVER  GROUP  9:  0 

SEBVER  GROUP  10:  13 

(clear  screen) 

(display  of  function  header) 

(display  of  the  routing  record) 


DO  YOU  WISH  TO  ADD  RECORD  TO  THE  DATA  BASE  ?  Y/- 
Y 

RECORD  SUCCESSFUL  ADDED 


DO  YOU  WISH  TO  EXIT  FUNCTION  ?  Y/ 
Y 


c.  Add  Servergroup  Record 


This  optics  is  used  to  add  a  servergroup  record 
to  a  simulation  model. 

Upon  selection  of  this  option  the  program 
prompts  the  user  for  entering  the  number  of  servers  for  each 
server  group  in  the  system  and  then  displays  the  record  for 
user  reviev.  At  this  point  the  .user  is  given  the  option  of 
adding  the  record  to  the  data  base.  If  the  user  chooses  not 
to  add  the  record,  the  message: 

RECORD  NOT  ADDED 

is  displayed,  otherwise  the  program  will  check  for  the 
existance  of  a  servergroup  record  for  that  model  in  the  data 
base  before  adding  the  new  record.  Depending  on  whether 
there  is  an  existing  servergroup  record  for  that  model,  the 
record  is  added  or  not  and  one  of  the  following  messages  is 
displayed  : 

RECORD  SDCCESSF01LT  ADDED 


or 


RECORD  ALREADI  EXIST;  NOT  ADDED 

This  function  is  not  repeated  because  there  is 
only  one  allowed  servergroup  record  per  simulation  model, 
and  the  user  is  returned  to  the  Update  Menu  on  entry  of  a 
character. 

An  example  of  the  user  program  dialogue  for 
adding  a  servergroup  record  is  illustrated  in  Pig.  4.18. 

d.  Delete  Jot  Type  Record 

This  option  is  used  to  delete  a  job  type  record 
from  the  data  base. 

Opon  selection  of  this  option  the  program 
requests  that  the  user  input  the  job  type  number  of  the  job 


****************4***************************** 

ADD  SERVER  GROUP  RECORD  FOHCTIOR 

************* 4 4* 4****** 44*4**** *************** 


SIHULATIOH  MODEL  MEMBER:  60 
ENTER  SOMBER  OF  SERVERS  FOR 


SERVER 

SERVER 

SERVER 

SERVER 

SERVER 

SERVER 

SERVER 

SERVER 

SERVER 


GROOP 
GROOP 
GROOP 
GROOP 
GROOP 
GROOP 
GROOP 
GROOP  8 
GROOP  9 


1 

1 

1 

0 

0 

0 

0 

0 

0 


(clear  screen) 

(display  of  function  header) 
(display  of  the  servergroup  record) 
DO  YOO  NISH  TO  ADD  THIS  RECORD  ?  I/- 
Y 


RECORD  SOCCESSFOL  ADDED 
BRIER  ARY  CHAR  TO  RETORH  TO  UPDATE  MENO 


Figure  4.18  Add  Servergroup  Record  Dialogue 


type  record  to  be  deleted.  If  the  job  type  does  not  exist  in 
the  data  base  the  following  message  is  displayed: 

RC  RECORD  FOUND 

otherwise  the  record  is  displayed  and  the  user  is  given  the 
option  of  deleting  it  from  the  data  base.  Depending  cn  the 
user  response  the  record  is  deleted  or  not  and  one  of  the 
following  messages  is  displayed: 

RECORD  SOCCE SSFOL1Y  DELETED 

or 


RECORD  NOT  DELETED 


at  the  end  of  the  function  dialogue  the  user  has  the  option 
of  exiting  function  or  atteapting  deletion  of  another  job 
type  record  for  the  sane  siaulation  nodel. 

HARNIBG  : 


RBEN  a 

1 

JOB 

TYPE  RECORD  IS  DELETED  ALL  THE 

ROUTING 

RECORDS 

WHICH 

ARE  SUBORDINATED  TO  THAT  J03 

TYPE  ARE 

ALSO  DELETED 

1 

e.  Delete  Routing  Record 

This  option  is  used  to  delete  routing  records  of 
a  sinulaticn  nodel. 

Upon  selection  of  this  option  the  prcgran 
reguests  that  the  user  input  the  job  type  nunber  and 
servergroup  number  to  which  the  routing  record  is  attached. 
If  either  the  job  type  record  or  routing  record  are  not 
found  in  the  data  base  an  error  message  is  displayed, 
otherwise  the  user  is  given  the  option  of  deleting  the 
specified  record.  Depending  on  the  user  option  the  record  is 
deleted  or  not  and  one  of  the  following  messages  is 
displayed: 

RECORD  SUCCESSFULLY  DELETED 


RECORD  ROT  DELETED 


At  the  end  of  the  option  dialogue  the  user  is  given  the 
option  of  exiting  the  function  or  deleting  another  routing 
record. 


f.  Delete  Server  Group  Record 


This  option  is  used  to  delete  the  server  group 
record  fros  the  data  base. 

Upon  selection  of  this  option  the  program  attempts  to 
locate  the  server  group  record  in  the  data  base.  If  the 
record  does  not  exist  an  error  message  is  displayed, 
otherwise  the  record  is  deleted  and  the  message 

RECORD  SUCCESSFULLY  DELETED 

is  displayed.  As  there  is  only  one  server  group  record  per 
simulation  model,  at  the  end  of  the  option  dialogue  user 
returns  to  Update  Menu  options  by  entering  an  arbitrary 
character. 

g.  Change  Jet  Type  Record 

This  option  is  used  to  change  model  parameters 
stored  into  a  job  type  record. 

The  program  first  reguests  that  the  user  input 
the  job  type  number  of  the  job  type  record  to  be  changed.  If 
the  record  does  not  exist  the  following  message  is 
displayed: 

CHANGE  ERROR  JOB  TYPE  NUMBER  NOT  FOUND 

otherwise  the  record  is  displayed  and  the  user  is  given  the 
option  of  selecting  the  i»odel  parameter  to  be  modified, 
arrival  distribution  type,  distribution  parameter,  or  job 
priority.  As  the  user  option  is  entered,  the  program  prompts 
for  input  data  according  to  the  model  parameter  selected. 
When  the  input  is  complete  the  user  has  the  option  to  select 
another  model  parameter  to  be  changed.  If  the  user  chooses 
to  modify  another  parameter  then  the  menu  of  options  for 
changing  of  model  parameters  will  be  displayed  for  another 
function  iteration.  Otherwise  the  entire  updated  job  type 
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record  will  be  displayed  for  user  review.  At  this  point  the 
user  is  given  the  option  of  exiting  the  function  or  changing 
another  job  type  record.  An  example  of  the  user  program 
dialogue  for  changing  a  job  type  record  is  illustrated  in 
Fig  4.19. 

h.  Change  Routing  Record 

This  option  is  used  to  change  the  lodel 
parameters  stored  in  a  routing  record. 

The  program  first  reguests  that  the  user  input 
the  job  type  number  of  the  job  type  record  to  which  the 
routing  record  to  be  changed  is  subordinated  and  then  asks 
the  user  to  identify  the  servergroup  number  of  the  routing 
record.  If  either  the  job  type  or  routing  record  are  not 
found  in  the  data  base  appropriate  error  messages  are 
displayed,  otherwise  the  user  is  given  the  option  of 
selecting  the  model  parameter  to  be  changed,  service 
distribution,  service  distribution  type,  gueueing  discipline 
or  routing  probabilities.  Opon  selection  of  the  model 
parameter  to  be  changed  the  program  prompts  for  entering 
data  according  to  the  option  selected.  Hhen  the  input  of  new 
data  is  complete  the  user  has  the  option  to  change  another 
model  parameter.  If  the  user  chooses  to  change  another 
parameter,  a  new  function  iteration  will  be  processed  for 
the  same  routing  record,  otherwise  the  routing  record  is 
displayed  and  user  is  given  the  option  of  exiting  the 
function  or  changing  another  routing  record. 

An  example  of  the  user  program  dialogue  for 
changing  a  routing  record  is  illustrated  in  Fig  4.20. 

i.  Changing  Server  Group  Record 

This  option  is  used  to  change  the  server  group 
record  for  a  given  simulation  model. 
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********************************************** 
CHARGE  JCB  TYPE  RECORD  FUNCTION 
*********************************************** 

SIMULATION  MODEL  SOMBER:  5 

ENTEB  NUMBER  OF  JOE  TYPE  TO  CHANGE: 

2 

SIMULATION  MODEL  NUMBER:  5 
JOE  TYPE  NUMBER:  2 

ARRIVAL  DISTRIBUTION  IS:  EXPONENTIAL 

DISTRIBUTION  PARAMETER  IS:  50 

JCB  PRIORITY  IS:  1 

ENTER  PARAMETER  YOU  NISH  TO  CHANGE 

1-  ARRIVAL  DISTRIBUTION 

2-  DISTRIBUTION  PARAMETER 

3-  JOB  PRIORITY 

2 

ENTER  EXPONENTIAL  EISTRIBUTION  MEAN 
100 

DO  YOU  NISH  TO  CHANGE  OTHER  PARAMETER  ?  Y/- 
N 

(clear  screen) 

(display  of  function  header) 

SIMULATION  MODEL  NUMBER  IS:  5 
JOE  TYPE  NUMBER  IS:  2 

ARRIVAL  DISTRIBUTION  IS:  EXPONENTIAL 

DISTRIBUTION  PARAMETER  IS:  100 

JOB  PRIORITY  IS:  1 

DO  YOU  NISH  TO  EXIT  FUNCTION  ?  Y/- 
Y 


Figure  *.19  Changing  Job  Type  Record  Dialogue 


Upon  selection  of  this  option  the  program 
attempts  to  find  the  servergroup  record  in  the  data  base.  If 


********************************************** 

CHANGE  HOOTING  BECORD  FUNCTION 

********************************************** 


SIKOIATION  MODE!  SOMBER:  60 
ENTER  BOMBER  OF  JOE  TYPE: 

1 

ENTER  BOMBER  OF  ROOTING  RECORD  TO  CHANGE 
1 
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3 


SERVICE  DISTRIBUTION  IS 
DISTRIBUTION  PARAMETER  IS 
QUEUEING  DISCIPLINE  IS 
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ROOTING 

ROOTING 

ROOTING 

ROUTING 

BOUTING 

ROUTING 

ROOTING 

ROOTING 

BOOTING 
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EROB  TO 
EROB  TO 
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EROB  TO 
EROB  TO 
EROB  TO 
EROB  TO 
EROB  TO 
PROB  TO 


t  IS 
2  IS 
‘  IS 
IS 
IS 
IS 
IS 

8  IS 

9  IS 
10IS 
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0 

0 

0 

0 

0 

0 

0 

0 

13 


EXPONENTIAL 

19 

FCFS 


PARAMETER  YOC  WISH  TO  CHANGE 

1-  SERVICE  DISTRIBUTION 

2-  DISTRIBOTION  TYPE 

3-  QUEUEING  DISCIPLINE 

4-  ROUTING  PROBABILITIES 


ENTER  QUEOEING  DISCIPLINE 

1- FIRST  COME  FIRST  SERVED  (FCFS) 

2- LAST  COME  FIRST  SERVED  (LCFS) 

3- NONPREMPTI VE  PRIORITY  (NP) 

4- SHORT.  PROC.  TIME  FIRST  (SPTF) 

5-  LOW.  WEI. PROC. TIME  FIRST  (IHPTF) 

6- PROCESSOR  SHARING  (PS1 

7- SERVICE  IN  RAND.  ORDER  (SIROV 

6 

DO  YOO  WISH  TO  CHANGE  OTHER  PARAMETER  ?  Y/- 
N 

(clear  screen) 

(display  of  function  header) 

(display  of  the  routing  record) 

DO  YOU  WISH  TO  EXIT  FUNCTION  ?  Y/- 
N 


Figure  4.20  Change  Routing  Record  Dialogue 
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the  record  is  not  found  an  error  aessage  vill  be  displayed, 
otherwise  the  number  of  servers  for  each  servergroup  vill  be 
prompted.  As  these  data  are  entered  the  updated  servergroup 
record  is  displayed  for  user  review.  The  user  is  returned  to 
the  UPDATE  MEND  by  entry  a  character. 

12.  summary  of  the  Manual  Contents 

This  CPMT  user's  manual  was  primarily  designed  for 
the  CS  4400  students  at  the  Naval  Postgraduate  School.  The 
first  section  introduces  the  simulation  program  to  the  new 
CPMT  users.  As  the  users  should  be  confortable  with  the 
model  design  before  CPMT  utilization,  the  next  section  of 
the  manual  describes  and  illustrates  with  an  example  the 
design  of  simulation  models  to  be  run  by  CPMT.  The  last 
section  explains  how  to  store  and  update  model 
specifications  in  the  simulator  data  base,  and  run  a 
simulation.  Some  examples  of  the  user  program  dialogue  are 
displayed  for  easier  familari2ation  with  the  simulator. 


T.  TESTING  END  VALIDATION 


The  objective  in  this  chapter  is  to  validate  the  CPMT 
ability  to  simulate  computer  systems.  To  accomplish  this 
validation  a  set  of  testing  models  was  run  and  the  output 
results  analyzed.  Tie  characteristics  of  the  testing  models 
include  CENT  capabilities  not  analyzed  by  Lt  Pagel  [Hef.  2] 
and  additional  enhancements  implemented  through  this  thesis 
effort. 

The  criteria  and  procedures  used  for  validation  are 
described  in  the  first  section,  followed  by  a  description  of 
each  experiment  and  an  interpretation  of  the  collected  data. 
A  summary  of  conclusions  is  presented  at  the  end  of  the 
chapter. 

1 .  Criteria 

The  overall  criterion  used  for  CPMT  validation  was 
that  the  conclusions  that  are  drawn  from  running  a 
simulation  model  on  the  simulator  should  be  the  same 
conclusions  that  would  have  been  drawn  from  evaluating  the 
model  in  analytical  form. 

A  random  sample  of  10  (n)  measurements  of  each  output 
parameter  is  collected  from  independent  simulation  runs. 
Based  on  this  sample,  a  two  tailed  hypothesis  test  is 
performed  or.  the  mean  value  to  decide  whether  the  simulation 
results  come  from  the  same  population  as  the  analytical 
results. 

Levels  of  significance  of  .05  and  .01  were 
established  as  acceptable  accuracy  bounds.  As  the  sample  is 
small,  it  was  assumed  to  come  from  a  student-t  distribution 
with  $  (12—  1 }  degrees  cf  freedom. 

The  null  hypothesis  is  the  following  : 
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where  is  the  sasple  aean  and  is  the  analytical 
paraaeter.  The  alternative  hypothesis  is  : 

H 

The  critical  values  obtained  froa  the  t-statistical  table 
for  the  levels  of  significance  and  degree  of  freedoa 
described  above  are  listed  in  Table  II. 


TABLE  II 

Critical  Values  froa  T-statistical  Table 


LEVEL  OP 
SIGHIFICAHCE 


CRITICAL 

VALUE 


0.05  1.833 

0.01  2.821 


The  sample  mean  is  transforaed  to  student-t  distribution 
by  eguation  5. 1  ,  where  is  the  analytical  paraaeter,  S  the 
saaple  standard  deviation  and  n  the  saaple  size. 

t  *  (  x  -yu*)/  (S  /  Vn)  (egn  5.1) 

For  a  given  saaple  the  null  hypothesis  is  rejected 
if  the  statistic  coaputed  froa  eguation  5.1  is  greater  than 
the  critical  value  for  the  level  of  significance  being 
considered.  Otherwise  the  null  hypothesis  is  accepted. 


2.  3s§t  £aag  11 

a.  Objective 


The  objective  is  to  test  the  sinulator  behavior 
for  a  deteraini stic  service  rate  and  independent  service 
deaand  queueing  discipline  (FCFS,  LCFS  or  SIBO) .  The  output 
paraaetex  to  be  aeasured  is  the  systea  throughput. 

b.  Si  aula  tier  Model 

The  siaulation  aodel  consists  of  a  single  server 
queueing  node!  in  which  the  arrival  rate  is  exponentially 
distributed  and  the  service  rate  is  constant  (M/0/1)  •  The 
interarrival  aean  and  service  aean  are  100  and  50 
respect ivelly.  The  aodel  is  to  be  run  independently  for 
FCFS,  LCFS  and  SIRO  queueing  disciplines. 

c.  Siaulaticn  Results 

The  siaulation  run  duration  was  specified  by  the 
nuaber  of  jobs  to  be  processed  and  the  output  results  are 
listed  in  Table  III. 

d.  Analytic  Eesults 

The  systea  throughput  for  a  single  server  aodel 
is  equal  to  the  arrival  rate.  As  the  interarrival  aean  for 
the  acdel  is  100  the  arrival  rate  and  throughput  rate  are 
equal  to  0.01. 

e.  Statistical  Analysis 

The  aean  and  standard  deviation  of  the  systea 
throughput  obtained  froa  the  sanples  are  listed  in  Table  IV. 
The  values  of  the  statistic  coaputed  froa  equation  5.1  using 
the  aean  and  standard  deviation  listed  in  Table  IV  are 
1.941,  2.395  and  2.678  for  FCFS,  LCFS  and  SIRO  queueing 
disciplines. As  these  values  are  less  than  the  critical  value 


TABLE  III 

Simulation  less Its  of 

Test  Case  #1 

BUM 

HUHBEB 

TEOUGHPOT  BATE 

* 

JOBS 

FCFS 

LCFS 

SIHO 

1 

15000 

55000 

0.0100 

0.0100 

0.0100 

2 

0.0100 

0.0100 

0.0100 

3 

22000 

0.0099 

0.0101 

0.0100 

4 

78000 

0.0100 

0.0099 

0.0100 

5 

34000 

0.0100 

0.0099 

0.0100 

6 

61000 

0.0100 

0.0099 

0.0100 

7 

92000 

0.0099 

0.0100 

0.0099 

8 

27000 

0.0100 

0.0100 

0.0099 

9 

100000 

0.0100 

0.0099 

0.0099 

10 

84000 

0.0100 

0.0099 

0 • 0 1 00 

- 

TIBI I  If 

Bean  and  Stdv  for  Test  Case 

*1 

DISCIP1INE 

BEAN 

STAND. DEV. 

FCFS 

0.00998 

0.0000327 

LCFS 

0.00996 

0.0000527 

SIRC 

0.00997 

0.0000353 

foe  the  0.01  level  of  significance  (2.821),  the  null 
hypothesis  is  accepted  for  all  the  gueueing  disciplines. 
However  as  the  sase  statistics  are  greater  than  1.833  the 
null  hypothesis  is  rejected  for  all  the  gueueing  disciplines 
if  the  0.05  level  of  significance  is  to  be  considered. 


3.  2§§t  saas  12 

a.  Objective 

The  objective  is  to  test  CPHT  for  simulation  of 
multiple  servers  within  a  servergroup.  The  parameter  to  be 
measured  is  the  mean  number  of  jobs  in  the  system. 

b.  Simulation  tlodel 

The  simulation  model  consists  of  a  H/B/2 
queueing  model  with  a  mean  interarrival  rate  of  20  and  a 
mean  service  rate  of  10. 

c.  Simulation  Besults 

The  simulation  run  duration  was  specified  by  the 
number  of  events  to  be  processed  and  the  output  results  are 
listed  in  table  7. 


d.  Analytic  Basalts 


The  sean  number  of  jobs  in  the  system  foe  the 
H/M/2  model  is  described  by  equation  5.2  where  the 
utilization  0  is  computed  from  equation  5.3  .  The 
utilization  obtained  from  the  last  equation  using  the  mean 
values  of  the  model  is  0.25.  Substituting  this  value  in 
equation  5.2  ve  get  0.533  as  the  mean  number  of  jobs  in  the 
system. 

E(N)  *  2*0  /(I-  0*)  (eqn  5.2) 

0  =  service  mean  /  (2  *  interarrival  mean)  (egn  5.3) 

e.  Statistical  Analysis 

The  mean  and  standard  deviation  of  the  number  of 
jobs  in  the  system  for  the  samples  shown  in  Table  V  are  : 

BEAN  STANDASE  DEVIATION 


0.535  0.016 

The  statistic  obtained  from  equation  5.1  using  the  mean 
and  standard  deviation  listed  above  is  0.4.  As  this  value  is 
less  than  the  critical  values  from  Table  II  ,  (1.833  and 

2.821)  the  null  hypothesis  is  accepted  for  0.05  and  0.01 
levels  of  significance. 

*»•  ISS t  Cas^  U 

a.  Objective 

The  objective  of  this  experiment  is  to  study  the 
CPBT  behavior  when  sisulating  jobs  with  different  priorities 
and  served  by  a  nonpreemptive  priority  queueing  discipline. 
The  output  to  be  measured  is  the  mean  time  in  system 
(response  time) . 


b.  Simulation  Model 


The  eodel  consists  of  a  single  server  queueing 
■odel  in  which  arrivals  and  service  tiae  occur  randoaly  with 
an  exponential  distribution.  The  workload  is  partitioned 
into  three  classes  of  jobs.  Each  job  type  has  a  given 
priority,  sean  interarrival  tine  and  aean  service  tiae,  as 
listed  in  Table  VI. 

Jobs  are  served  in  a  nonpre-entive  priority 

schedule. 


Characterist ics 

JCB  THE  PRIORITY 

TABLE  VI 

of  each  Standard  Type 

HEAR  INTERARRIVAL 

of  Job 

HEAR  SERVICE 

1 

1 

200 

50 

2 

2 

500 

125 

3 

3 

2000 

500 

c.  Siaulaticn  Besults 

The  simulation  run  duration  was  specified  by 
siaulation  tine  and  the  sample  of  output  results  is  listed 
in  Table  VII. 

d.  Analytic  Besults 

The  aean  response  tiae  for  all  jobs  and  for  each 
job  type  for  this  model  are  taken  from  [Bef.  Y  :p.77],  and 
are  shown  in  Table  VIII. 
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TAB LB  BIX 

Simulation  Basalts  of  Test  Case  #3 


SIMUL 

BEAM  TIME 

IN  SYSTEM 

TIME 

ALL 

TYPE  1 

TYPE  2 

TYPE  3 

123000 

505.8 

291.8 

611.4 

2311.8 

155000 

410.5 

250.4 

511.8 

1623.1 

240000 

438.0 

265.2 

574.9 

1698.3 

480000 

762000 

482.6 

294.4 

597.9 

1888.6 

499.6 

296.8 

628.6 

2038.4 

261000 

490.1 

295.1 

588.8 

2046. 1 

943000 

397.1 

243.1 

529.4 

1423.  1 

335000 

478.9 

im 

604.3 

1984.7 

433800 

452.2 

565.2 

1785.2 

692000 

457.3 

267.0 

583.7 

1847.0 

TAB LB  fill 

* 

Analytical  Solution  of 

Test  Case  §3 

TYPE 

BESPONSE  TIME 

ALL 

460 

TYPE 

1 

275 

TYPE 

2 

575 

TYPE 

3 

1850 

tatistical  Ana 


xne  lean  and  s 
pies  are  listed 


TABLE 

IX 

■ean 

and  stdv  for 

Test  Case  *3 

JOB  TYPE 

MEAN 

STANDARD  DEVIATION 

AIL  JOBS 

461.2 

37.  1 

TYPE  1 

275.  8 

19.4 

TYPE  2 

579.6 

36.2 

TYPE  3 

1864.  6 

250.  7 

The  statistic  values  computed  from  equation  5.1  using  the 
aean  and  standard  deviation  listed  in  Table  IX  are  0.1, 
0.04,  0.40  and  0.18  for  all  jobs  and  for  each  job  type.  As 
these  values  are  less  than  the  critical  values  1.833  and 
2.821  the  null  hypothesis  is  accepted  for  all  jobs  and  for 
each  job  type  for  0.C5  and  0.01  levels  of  significance. 

5.  Test  Case  #4 

a.  Objective 

The  objective  of  this  experiment  is  to  test  CPNT 
for  simulation  of  closed  network  gueueing  models.  The  output 
parameters  to  be  measured  are  the  server  utilizations. 

b.  Simulation  Hodel 

The  simulation  model  consists  of  a  closed 
gueueing  central  server  model  which  was  already  described  in 
detail  in  Chapter  4  of  this  thesis. 

c.  Simulation  Results 

The  simulation  run  was  specified  by  simulation 
time  and  the  output  results  are  listed  in  Table  X. 


TABU  X 

Siaalatian 

Results  of 

Test  #4 

BOH 

SIMULATION 

UTILIZATIONS 

* 

TIME 

CPO 

HARD 

FLOPPY 

1 

133000 

0.  948 

0.  416 

0.343 

2 

411000 

0.953 

0.416 

0.339 

3 

325000 

0.966 

0.  403 

0.347 

4 

127000 

0.967 

0.449 

0.310 

5 

251000 

0.  937 

0.409 

0.346 

6 

531000 

0.  968 

0.423 

0.343 

7 

301000 

0.939 

0.  443 

0.343 

8 

210000 

0.  864 

0.360 

0.340 

9 

442000 

0.957 

0.449 

0.335 

10 

536000 

0.974 

0.436 

0.332 

d.  Analytic  Eesults 

The  numerical  solution  for  the  model  coapated  by 
the  IBM  software  simulation  package  RASQ,  according  to 
LAVENBERG  [Ref.  1  : p.378 estimates  the  following  server 

utilizations  : 

CPO  .  0.95 

HARD  DISK .  0.42 

FLOPPY  DISK...  0.33 

e.  Statistical  Analysis 

The  mean  and  standard  deviations  for  the  server 
utilizaticns  obtained  from  the  sample  are  listed  in  Table 
XI. 
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TABU  XI 

Bean  and  Stdv  for  Test  Case  ft 


SERVER 

HEAR 

STANDARD  DEVIATION 

CPU 

0.947 

0.017 

HARD  DISK 

0.420 

0.027 

FLOPPI  DISK 

0.337 

0.011 

The  statistics  computed  froa  equation  5.1  using 
the  aean  and  standard  deviations  listed  in  table  XI  are  0.57 
,  0  and  2.23  for  CPU,  HARD  DISK  and  FLOPPI  DISK.  As  all 
these  values  are  less  than  the  critical  value  for  the  0.01 
level  of  significance  (2. 821),  the  null  hypothesis  is 
accepted  for  all  server  utilizations.  For  the  0.05  level  of 
significance,  as  the  critical  value (1. 833) is  less  than  the 
statistic  found  for  the  FLOPPY  DISK  utilization  (2.23)  and 
greater  than  the  values  found  for  CPU  and  HARD  DISK  (0.57 
and  0),  the  null  hypothesis  is  rejected  for  the  first  server 
and  accepted  for  the  last  two  servers. 

This  result  is  not  surprising  because  the 
branching  probabilities  assigned  to  the  CPHT  model  were 
rounded  from  the  original  model. 

6-  l££t  Cass  15 
a.  Objective 

The  objective  of  this  test  case  is  to  estimate 
the  CPHT  performance  for  simulation  of  more  complex  models. 
To  accomplish  this  estimation  a  hypothetical 
terminal-oriented  distributed  computing  system  was  modeled. 
The  parameters  to  be  measured  are  the  system  throughput  and 
mean  time  in  system. 
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t.  The  Systea 


The  computer  system  to  be  modeled  was  adapted 
from  1BIVEDI  [Bef.  3  :p. 441],  and  it  is  a  distributed  system 
which  primarily  services  three  5  terminals  (T) .  The  system 
includes  four  processors,  a  front-end  (F) ,  a  communication 
processor  (C) ,  a  DBMS  processor  (0)  and  the  principal 
element  processor  (P) . 

A  single  class  of  jobs  is  processed  and  there  is 
one  job  assigned  to  each  terminal.  The  branching 
probabilities  are  described  by  the  matrix  in  Figure  5.1. 


T 

F 

C 

0 

P 

T 

0 

1 

0 

0 

0 

F 

0.8 

0 

0.2 

0 

0 

C 

0 

0.458 

0 

0.333 

0.209 

D 

0 

0 

1 

0 

0 

P 

0 

0 

1 

0 

0 

Figure  5.1  Branching  probabilities  llatrix 


The  average  think  time  of  a  terminal  and  the 
average  service  times  for  the  processors  are  assumed  to  be 
exponential  distributed  with  the  mean  values  as  listed  in 
Figure  5.2. 

c.  Simulation  Model 

The  model  consists  of  a  closed  queueing  network 
with  five  codes.  A  job  spends  a  think  time  at  the  terminal, 
traverses  the  subnetwork  of  processors  and  when  it  completes 

3A  saall  number  of  terminals  was  simulated  to  facilitate 
the  analytical  soluticn 


K 


SERVER 


TERMINAL 
PROCESSOR  F 
PROCESSOR  C 
PROCESSOR  D 
PROCESSOR  P 


AVERAGE  TINE 


15  sec. 
0.67  sec. 


1  sec. 
5  sec. 
5  sec. 


Figure  5.2  Average  Think  and  Service  Tiaes 

has  another  think  tine.  Each  processor  is  modeled  by  a 
serveigroup  with  a  single  server.  The  set  of  terminals  is 
modeled  hy  a  servergroup  with  multiple  servers.  The  CPMT 
model  and  servergroup  data  fora  are  illustrated  in  Figures 
5.3  and  5.4. 

Because  the  saallest  time  is  in  the  0.01  sec 
range,  see  Fig  5.2  ,the  time  values  are  multiplied  by  100 
for  routing  record  data  input.  As  the  routing  protatilies 
from  a  given  servergroup  must  be  represented  as  integers  and 
the  sum  must  be  equal  to  100,  the  probabilities  from  the 
branching  matrix  shewn  in  Figure  5.1  are  rounded  to  meet 
this  criterion.  The  job  type  and  routing  record  data  form 
for  the  model  are  illustrated  in  Figure  5. 5. 


d.  Simulation  Results 

The  simulation  run  was  specified  by  simulation 
time  and  the  output  results  6  are  listed  in  Table  XII. 


•Output  values  are  divided  by  100  to  convert  to  1  sec. 
time  unit  1 


SGO 


SGJO 


SGI 


SG4 


SG3 


SG2 


SG  5 


— 

Simulation 

Nuaber  :  99 

■  -  - i 

Serveryroup 

Nuaber  : 

Nuaber  of  Servers  : 

1 

3 

2 

3 

1 

4 

1 

5 

1 

6 

0 

7 

0 

8 

0 

9 

0 

Siaulation  Huaber  : 

99 

Job 

Type 

Huaber  :  1 

*****************  job  TIPS 

RECORD 

*************** 

Arrival  Dist  :  - 

Dist  Paran  :  _ 

Priority  :  1 

****************  BOOT  1 116  RECORD  ***************** 

Servergroup  : 

0  1 

2 

3 

4 

5 

6  7  8  9 

Service  Dist: 

2 

2 

2 

2 

2 

Cist  Paran  : 

-  1500 

67 

100 

500 

500 

Queue  Disc  : 

1 

1 

1 

1 

1 

Routing  To  : 
SG  1 

100  - 

80 

m 

m 

SG  2 

-  100 

— 

46 

— 

— 

SG  3 

—  — 

20 

— 

100 

100 

SG  4 

— 

— 

33 

— 

SG  5 

—  — 

— 

21 

— 

— 

SG  6 

—  — 

— 

— 

— 

— 

SG  7 

—  — 

— 

— 

— 

— 

SG  8 

—  — 

— 

— 

— 

— 

SG  9 

Figure  5.5  Job  Type  and  Boating  Record  Data  Forn  of  Test  #5 
e.  Analytic  Results 

The  analytic  procedure  used  to  solve  the  network: 
■odel  was  extracted  froa  TRIVEDI  [Ref.  3]. 

Fron  the  branching  probabilities  listed  in  Fig 
5.1  we  get  the  following  systen  of  linear  eguations  for 
coaputation  of  relative  throughputs  V;  's  of  the  network 
nodes  : 

tT*  0.8 

VF=  VT*  7C*  0.458 

7c*  V  0.2  ♦  % 

7  *  7  *  0.333 

2  C 
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Simulation  Resalts  of  Test  Case  #5 


SIMULATION 

TIME 


TBHOUGHPCJT 

RATE 


MEAN  TIME 
IN  SYSTEM 


2981300 
17804CC 
3173500 
234600 
1995000 
23421 CC 
38120  00 
890000 
5678800 
212000C 


Q.  16 


18.707 

18.322 

18.211 

17.941 

17.763 

18.401 

17.973 

17.883 

18.199 

18.074 


Yp=  Vc*  0.209 


Choosing  VT  =  1  and  solving  the  systea  of  equations  ve  find 

the  following  relative  throughput  for  the  reaaining  nodes  : 


Vr=  1.25 


0.546 


V  =  0.182 
v 

Vp=  0.114 


The  relative  utilization  of  node  i  is  given  by  the  equation 
5.4  where  Vt-  is  the  relative  throughput  and  E(S)  the  service 
tine. 


(1*  v*  *  E(S) 


(egn  5.4) 


Substituting  the  service  tines  from  figure  5.2  and 
throughput  in  eguaticn  5.4  ve  get  the  following  relative 
utilizations  : 


V  . V*.  \ 


'' •*“»'*.**  »*•  ■*  ,*•  «"■  »'•  « *• 

■«  A  A'V  A'.n’.'.'A'a'.'.'A'  Vl-.V\'‘oVa'\‘‘.' 


The  average  systen  throughput  is  given  by  equation  5.5  where 
H  is  the  nusber  of  terainals  and  C  is  the  normalization 
constant. 


THOOGHGHFOT  *  C(l!  -  1)/C(H) 


(egn  5.5} 


The  computation  cf  nornalization  constants  is  performed  by  a 
recursive  scheme  based  on  the  eguations  5.6  ,  5.7  and  5. 8  , 
where  c  is  the  nunber  of  servers  at  node  i#  and  B;(k t)  the 
joint  prctability  of  k  jobs  at  node  i. 


3 \  (*i )  = 


K  i  ?  K.  <Ci 

.  **"C; 

C,!C4  *>C 


(egn  5.6) 


RJk)  = 


**0 

I  KsO 


(egn  5.7) 


Ct0)  = 


**Ui 

ito 

/  KaO  *” 

|  *.  UJ  i«  o 


(egn  5.8) 


The  values  obtained  for  C(2)  and  C(3)  are  160.16  and  965.8. 
Substituting  these  values  in  equation  5.5  we  found  0.166  as 
the  analytic  troughput  rate. 


The  analytic  response  tine  is  obtained  froa  the 

eg nation 

RESP0H5E  THE  -  M  /  TROUGH EOT  -  THIIK  TIBS 

Substituting  the  nunber  of  terainals  3,  throughput  0.166  and 
think  tine  15  sec.  in  the  equation  above,  we  get  3.116  sec. 
as  the  analytic  response  tine.  As  the  parameter  tc  be 
coapared  is  the  Bean  tine  in  the  systea  we  have  to  add  the 
average  think  tiae,  15  seconds  to  this  value  to  find  the 
analytic  result  which  is  18.116  sec. 

f.  Statistical  Analysis 

The  saaple  aean  and  standard  deviation  for 
throughput  and  aean  tiae  in  systea  are  listed  in  Table  XIII 


TABLE  XIII 

Bean  and  Stdv  of  Test 

Case  #5 

TRCOGHPOT 

HUE  IB  SYSTEM 

BEAN 

0.165 

18.147 

STDV 

0.005 

0.427 

The  statistics  obtained  froa  equation  5. 1  using  the  values 
of  Table  XIII  are  0.625  and  0.23  for  throughput  and  response 
tiae.  As  these  statistics  are  less  than  the  critical  values 
for  the  0.01  and  0.C5  levels  of  significance  (2.821  and 
1.833),  the  null  hypothesis  is  accepted  for  both  accuracy 
hounds. 


•  1 1 


.«)  • 


fro*  the  results  of  statistical  tests  performed  on 
the  population  mean  for  different  output  paraaeters  and 
siaulation  aodels  we  conclude  that  the  simulation  results  do 
not  differ  significantly  (at  0.01  and  0.05  levels  of 
significance)  from  what  would  be  the  analytic  results. 

The  accuracy  of  results  could  be  improved  by 
extending  the  precision  of  the  branching  probabilities  to 
bring  then  in  closer  correlation  with  the  siaulated  sy stews. 

Ihe  coaplexity  of  the  analytic  procedure  which  was 
reguired  to  obtain  nuaerical  solution  for  the  performance 
paraaeters  of  the  distributed  sytea  (Test  Case  95) 
illustrates  the  advantage  of  using  siaulation  techniques  for 
evaluation  cf  coaputez  systeas. 


fl.  COHCmSIOM 


Maintenance  of  a  software  product  is  considered  to  begin 
from  the  time  that  the  program  becomes  operational  and  is 
primarily  concerned  with  changes  to  reflect  expansion  of 
reguirements.  This  thesis  was  intended  for  enhancement  of  an 
operational  simulation  program  (CPMT)  in  areas  such  as 
modeling  capability  ,  simulation  run  flexibility ,  processing 
efficiency  and  user  friendliness. 

A  new  class  of  gueueing  network  models,  closed  network, 
and  five  additional  gueueing  disciplines.  Last  Cone  First 
Serve,  Serve  in  Random  order,  Honpreemptive  Priority,  Short 
Processing  Time  First,  and  freighted  Short  Processing  Time 
First  were  made  available  in  the  new  version  of  CPHT  to 
increase  the  modeling  flexibility.  However  further 
enhancement  could  be  done  in  this  area.  Extension  of  the 
network  models  in  order  to  include  multiple  sources  and/or 
sinks,  and  passive  gueues  are  examples  of  potential  topics 
for  enhancement.  Assumptions  of  the  simulator  design  such  as 
the  server  be  always  serving  a  job  when  jobs  are  present  and 
infinite  capacity  of  the  servergroups  nay  not  be  true  in 
some  acdel  applications  and  therefore  they  can  also  be  the 
object  of  research.  Finally,  pre-emtive  gueueing  disciplines 
such  as  Last  Come  First  Served  Preemptive  Resumed  (LCFSPR) 
and  Preemptive  Priority  (PP)  are  not  implemented  and  could 
be  useful  for  modeling  of  some  real  systems. 

The  modified  program  provides  alternative  methods  of 
specifying  the  simulation  run  duration.  Simulation  time  and 
number  of  events  to  be  processed  are  new  options  to  define 
the  period  of  tine  a  simulation  is  to  be  run. 

The  memory  reguirements  of  the  program  were 
significantly  reduced  by  changing  the  space  complexity  of 


the  algorithm  for  job  generation.  Sizable  sianlations  can  be 
run  in  the  see  version  without  any  systea  limitation. 

k  large  nuaber  of  changes  was  introduced  in  the  prograa 
operation  in  response  to  criticise  of  CPHT  users  and  as 
result  of  our  intensive  utilization  of  the  prograa.  The 
evaluation  of  the  current  prograa  user  friendliness  can  only 
be  done  ty  further  CPHT  utilization. 

The  accuracy  of  the  results  vas  discussed  in  detail  in 
the  last  chapter  and  demonstrates  the  CPHT  ability  to 
siaulate  computer  systems  represented  by  open  or  closed 
queueing  network  aodels.  Further  it  has  been  demonstrated 
that  the  time  and  work  required  for  computer  modeling  and 
siaulaticn  using  CPHT  are  relatively  constants  regardless  of 
the  complexity  of  the  simulation  models  to  be  run. 
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